Rss

Archives for : xcode

Xcode Treasures: Platform Specifics

The third update to the Xcode Treasures beta book went out yesterday, and this is a good one: it’s all about platform-specific features.

Table of contents for chapter 12

Continue Reading >>

Follow-up: How to Build an Xcode Project that Builds for Both iOS and macOS

Since I talked about making multi-platform projects like it was no big deal in my blog yesterday, I figured I should at least back that up.

macandiosbuilddemo (GitHub link) is an Xcode project that builds an iOS master-detail app and a macOS windowed app from the same code base. It’s fairly trivial and unpolished, just fetching a JSON feed from this blog, showing recent entries in a table, and letting you drill into one.

Side by side iOS and macOS apps, built from the same Xcode project

Continue Reading >>

Apple Didn’t Kill AppKit, Millenials Did

(yes, thank you for indulging my outrageous clickbait headline, which wildly misrepresents the contents of this blog post)

Two weeks after WWDC, and we’re all still talking about Marzipan, the de facto name for UIKit-on-macOS that was acknowledged in the keynote. Like, seriously, as I’m typing this Colin and Steve are arguing about it, so everyone who follows both of them gets to watch.

Craig Federigi showing diagrams of macOS/iOS app architectures

It won’t even be available to developers for another year, so we have lots of time to argue, and to enjoy the unintended consequence of Osborning macOS’ AppKit framework.

But… what if this is all sound and fury, signifying nothing? What if tasty Marzipan turns out to be a big Nothingburger? Because that could well be how it pans out instead.

Continue Reading >>

Xcode Treasures: Source Code Management

Another update to the Xcode Treasures beta has been released today. This one is all about Source Code Management.

Scm toc

Continue Reading >>

Xcode Treasures: Security

The first update to the Xcode Treasures beta release went out yesterday, and it’s a doozy: Security. Actually, in my original proposal and outline for the book, this was called Code-Signing Hell. Obviously, I knew I had to cover it, but was not looking forward to the experience.

Xcode treasures security toc

Continue Reading >>

Xcode Treasures Now Available

Announcement from Pragmatic Progammers today: Xcode Treasures: Master the Tools to Design, Build, and Distribute Great Apps is now in beta.

So, this is the book that I’ve been cagily dropping hints about on Twitter for months, and that I showed off at CocoaHeads Ann Arbor two weeks back. I’ve also started creating videos for it as part of invalidstream, where you can already check out demos from the Debugging chapter (parts 1, 2, and 3).

Continue Reading >>

RxNot

A few weeks back, I tweeted:


The stealth message here was that there’d been a mass layoff, and as such, I’m no longer at MathElf. (Aside: which means, for the moment at least, I’m available for contract work: cadamson@subfurther.com).

While I’m not about to slam my ex-employer, I do want to get in a word about a key technology we used that left me cold. As the tweet indicates, this is gonna be about RxSwift.

Continue Reading >>

Let It Snow

I’m not the first to say this. Chances are you saw Marco Arment tweeting about it earlier in the week:

The latter half of 2014 has been a disaster in terms of quality of Apple software. As I was finishing up the book, I kept an index card of all the bugs I needed to file. I ran out of room.

List of bugs to file

Some of these have caused real pain, such as the Xcode 6.1 iOS Simulator not supporting internationalization — horrible for us when the third chapter of our iOS 8 SDK Development book walks through an i18n example, and a later chapter shows how to make a third-party keyboard extension, which doesn’t work because the simulator now only supports the US English and emoji keyboards.

Continue Reading >>

Social Swift Style Survey #1

So, Xcode 6 beta 7 came out today, and with it, lots of changes to the Swift APIs for iOS and OS X. Mostly, it’s the ongoing removal of the ! character from parameters and return types. The bang is an implicitly-unwrapped optional, meaning it’s an optional — a variable that may or may not have a value at all — but since having to check lots of variables against nil and unwrap them would be burdensome, you’re allowed to treat it like a normal non-optional variable. Only downside is that your app crashes if you don’t unwrap and it turns out to be nil.

In the early Xcode 6 betas, nearly every parameter in Apple APIs was a bang, since they had to be optionals (nils were commonplace in Objective-C), but Swift adoption would have been hindered if we’d spent June through August unwrapping them.

For the last few betas, Apple engineers have been doing yeoman’s work, going through all these APIs and identifying what must be an optional, and what doesn’t need to be. So, the bangs are disappearing, replaced by either ? for honest-to-goodness optionals that should be tested against nil, or empty space, indicating the variable will always have a value.

If you’re writing a lot of Swift code — say, for a beginner’s book with 30+ versions of your sample code app — you’re used to each new build breaking your code, and forcing you to do through and make some pretty simple edits to deal with API changes as the bangs disappear.

Swift compiler errors caused by removal of implicitly-unwrapped optionals in Xcode betas

In some cases, it’s making me do unwraps where I’d previously been playing fast and loose with the bang-type. And that brings me to a question. There are two ways to do unwraps, and I’m not exactly in love with either of them.

Here are two examples. In beta 7, all the UIViewController properties for finding parent containers (navigationController, splitViewController, tabBarController) have all become full-on optionals, so a reference to self.splitViewController.delegate no longer works. One way to deal with this is to explicitly test for nil, and then use the bang operator to unwrap inside the if block.


if self.splitViewController != nil {
    self.splitViewController!.delegate = self
}

This is OK, except that when you have a non-trivial number of lines in the block, all the bangs seem dirty. We can avoid this with option #2: casting to a non-optional type in the if:


if let validSplitViewController = self.splitViewController {
    validSplitViewController.delegate = self
}

Fewer bangs, but now I’m burdened with coming up with a name for the non-optional version of the variable. And good variable names are hard to come up with. Heck, what’s even a good convention for this? validFoo? unwrappedFoo? safeFoo? It feels like I’m polluting my code with more variables to keep track of.

Since I’m not pair-programming or working with a lot of people producing Swift code, I’m not sure which is becoming the preferred idiom, and I don’t want to inadvertently write a book of my own idiosyncratic coding style.

Next best thing… a poll! Let me know what you think, and I’ll ack back at some point with the results.

[iframe src=”https://docs.google.com/forms/d/1YD2bQ4-KUJzZzB2nkKqu2TsCedVIlC8Viqwrys04TME/viewform?embedded=true” width=”500″ height=”400″ frameborder=”0″ marginheight=”0″ marginwidth=”0″ Loading…]

Thanks in advance for your votes, comments, and pre-orders.

RESULTS UPDATE (Sept. 5): After a couple days and 38 votes, results are:

  • 26 votes for Use if let / if var to unwrap to a new variable
  • 5 votes for Test against nil, unwrap with !
  • 7 write-ins, almost all for an optional-chaining alternative I failed to mention: self.splitViewController?.delegate = self

Asynchronous Unit Testing in Swift: The Good, Ugly The Bad, And The

Janie Clayton-Hasz and I are working on the unit testing chapter for the still-unannounced book, and we’ve had enough fun that we decided to share a little bit of what we’re up to.

In the previous edition, I wrote a testing chapter based on Bill’s iCloud recipes project, and it was a nightmare for a couple of reasons. First, a completion handler that was supposed to be called from -[UIDocument closeWithCompletionHandler:] wasn’t, at least not in iOS 6. Second, iCloud sucks (c.f., “First”). And finally, the whole idea of testing something that takes an unknown amount of time is an interesting problem, one that OCUnit was not built to handle.

So it was really cool that Janie did the research and came back with promising results about asynchronous unit testing in iOS 8 / Xcode 6. Then we jumped into the chapter and… well, it’s not as pretty as the WWDC video would have you believe. It works, but sometimes you have to play a little dirty to get it there.

Continue Reading >>