• I’m joining Apple full-time as a Software Engineering Author, starting Monday 7/23/18.
• The Xcode Treasures book is now complete, with my having just turned in the last chapter to my editor.
• Given corporate policies on outside activities, I won’t be blogging here anymore.
• I also won’t be speaking at conferences.
• Not sure about the livestream, which is on a Summer hiatus anyways. It might return, but in a very different form.

Obviously, you should unfollow me on Twitter right now, because I won’t be tweeting about development topics anymore, which means my posts will be nothing but anime and complaining about parenting.

So, I haven’t been too public about this, but I’ve actually been working for the last year as a contractor in Apple’s Developer Publications group. Earlier this year, they asked if I wanted to interview to come on full-time, but I said I wanted to finish Xcode Treasures first, because I thought it was an important book and I wanted to see it through. So, as the book work was in the final stretch last month, I went out to Cupertino for a round of interviews.

So, why board the mothership? Well that should be obvious: to get in on the sweet employee discount before the Mythical Modular Modern Mac Pro comes out next year. 20% (or whatever it is) off a $7,500 configuration is serious coin, bucko.

But seriously, I actually like what they’re doing with developer publications. It’s not my place to say why they’re doing things the way they are, but if you step back and let yourself compose a thoughtful and complete understanding of the form, state, and use of developer documentation, you may realize what DevPubs is up to is the right thing to do.

Now I know there are people out there who are all like “But… but my wall of API diffs that I look at every WWDC Monday night and then never again!” Trust me — the other 364 days of the year will eventually be worth it.

(Also, anytime you’re going to take one of these “the big company doesn’t get it, but I do” stances, I think it’s important to commit: either full-on TRON cosplay as you shout “I fight for the users!”, or see if you can get Bruce Boxleitner to come on your podcast.)

Of course, for me, there’s also the idea of job security, which is reassuring after facing challenges with the ups-and-downs of the app economy over the years. With two kids, one of whom has severe medical issues, getting on a company health plan will be extremely helpful to our family’s financial well-being.

Consequences

That said, surely you’ve noticed that all the people who leave the public sphere to work at Apple get real quiet. That’s to be expected. Obviously, they can’t talk about anything secret they’re working on.

But even if I’m working on, say, some ancient thing in Foundation, does my publicly expressing an opinion on URLConnection (It sucks! Migrate to URLSession already!) mean that my employer is saying that? Of course not. But people will take it that way. In particular, some people with an axe to grind with a company will find the most contentious thing any employee has said and try to hang it on the employer. And it often works. Best way to avoid getting fired over saying something stupid? Don’t say it in the first place. (Did I mention I really need health coverage?)

But I’ve been particularly public for the last decade, after coming over from Java to Cocoa. So here’s the plan for all the stuff I’ve got out there:

• This will probably be the last blog post for the foreseeable future. While this is a “digital media development blog”, according to the banner, the whole topic area hits too close to Apple’s businesses for comfort. For example, the rivalry of HEVC, VP9, and AV1 would be fun to write about, but Apple is very much involved in that fight (having adopted HEVC, but also being on the board that guides AV1), so even talking about those topics in an objective manner is likely a conflict of interests. Good thing Streaming Media just covered the codec wars in a new article.
• I submitted the final chapter of Xcode Treasures a few days ago, and will clean up the remaining errata and as much tech reviewer feedback as I can before going pencils-down on Monday. I don’t feel like this book has found its audience yet, and I regret that I won’t be able to promote it further, but since the changes in Xcode 10 are rather modest, it shouldn’t need updating either and may have a pretty long shelf life.
• I don’t know what I’m going to do with Invalidstream. I really enjoy making it, but the viewership is nearly zero, and I obviously can’t do a half-hour of iOS/Mac developer lessons every week anymore. In fact, even the second segment—let’s plays of iPad games—is a conflict of interest, because of the whole “@invalidname said Madden NFL for iPad is boring-ass lootbox garbage, so now I’m mad at Apple” problem. Maybe I’ll bring it back as PS1/PS2 retro-gaming, anime reviews, and/or visual novel read-alongs, I just don’t know. Let’s see how I feel once summer’s over.
• Obviously, I’m going to lay off the tech tweets and snark about Apple and the iOS/Mac APIs on Twitter, so you really, really should unfollow me. This means you, Marco. Six months from now, my Twitter posts may consist entirely of fast food wine pairings, and excerpts from my five-volume Muv-Luv fanfic / epic takedown of Trumpian white nationalism.

You Talk Too Much

The other obvious thing I’m dropping is speaking at developer conferences, but to be honest, I did that months ago. When I was asked about participating in Swift By Northwest, I said I was happy to help promote it, but was not interested in speaking anymore.

This was a decision I came to after the poor reception to what I thought was one of the better talks I’d ever done. Since so many of these conferences use “Swift” in their name now, I thought it would be disingenuous to just do a random cool-new-framework talk, so to do something really about Swift, I dug into the idea of how Apple’s media frameworks push Swift farther than it is currently able to go, and what we should do in the meantime until Swift matures.

The reaction wasn’t what I’d hoped. Attendees found the jokes unfunny (or even inappropriate) and didn’t really care for the message that there are some things that, for now at least, should still be written in C or C++. But the real killer was that people weren’t interested in my speaking at all. There aren’t a lot of feelings quite as bad as people deliberately fleeing you, but that’s exactly what happened to me at the single-track Swift by Northwest:

Best thing about my conference talks is how they can consistently clear out the room before they even begin. pic.twitter.com/Pbs5Fx5B1z

— Chris Adamson (@invalidname) October 27, 2017

13/ I thought this was possibly the best talk I’d ever done, at least by Chicago when I got the Audio Unit working, but the feedback was actually pretty negative. And the sight of all my friends fleeing the room in Seattle was too much to take. I’m not doing any talks in 2018.

— Chris Adamson (@invalidname) January 1, 2018

So, yeah, what I’m selling, nobody’s buying. Sounds like a perfect time to close up shop.

The Good Fight

It’s good to keep challenging yourself, to never get comfortable (usually not a problem for me, but still). On the Xcode Treasures book, editor Tammy Coron has pushed back a lot harder than most of my previous book editors, and has a strong sense of process, so that’s been good for me to work through. (Also, the interview I did with her and Tim Mitra for the Roundabout: Creative Chaos podcast is easily the most interesting of the few interviews I’ve ever done, so it’s nice that exists).

At Apple, the rigor I’ve been put through by mentors and editors is like on a whole other level. It’s really exacting, from the top-level strategy of docs, articles, and sample code, to the nit-picky ground game of copy-editing. You really have to think through what you’re doing, how it works, and what your readers are going to get out of it. You can’t finesse or hand-wave your way out of problems in your narrative; you have to face them head on. It takes a lot of work to get things to a point where all parties approve them.

But hey, at my age, learning new things is not something to be feared; it’s a challenge to be embraced.

And again, don’t forget to unfollow me on Twitter if you haven’t already (but you probably already have).

While the book sort of takes Swift + iOS as its default stance, I’ve used Mac examples where it makes more sense to do so, and I drop into Objective-C or C when I need to for language-specific reasons (like showing off certain debugging or profiling features). But this chapter is specifically about features in Xcode that only make sense for one platform, or that combine multiple platforms.

In part, this came from the fact that I knew from day one that I really wanted to do a section about writing command-line apps, since they’re short and useful and fun, and people don’t always realize that you even can write them with Xcode. There’s even a little bit of guidance for how to turn them into daemons or agents, and get them to the user’s computer via an Installer package, although Xcode is of no help whatsoever for doing install stuff, so I sort of have to point you in the right direction (pkgbuild and productbuild) and leave it at that.

There’s also a fair amount of tvOS stuff — on-demand resources and how you set those up in the project to have Apple host them for you, and building the layer stack images for app icons. For watchOS developers, Jeff Kelley suggested a useful and hard-to-find feature: setting up your own pairings of iPhone and watch simulators. Y’know, for those times you want to pair the newest iPhone with the oldest Apple Watch.

One particularly important part of the chapter is setting up a project to build for multiple platforms from the same codebase. I’d originally written it to add a tvOS app target to an iOS example from earlier in the book, but after editor Tammy Coron made a suggestion about reorganizing the sections of the chapter, I saw an opportunity to do this example as an iOS+Mac demo instead. Obviously, this was fresh on my mind after last week’s blogging, and will hopefully spur readers to take the leap into cross-platform projects now, instead of waiting a year for Apple’s well-at-least-it’s-not-Electron solution.

True story: Tammy’s suggestion was actually about changing the flow to put watchOS before tvOS. As a consequence, this moved multi-platform between command-line (macOS) and watchOS, so making the multi-platform section be about Mac made for better flow out of the command-line material (since both are Mac) and into watchOS (since watchOS projects are by their nature multi-platform). It’s like it was meant to be, y’know? So I actually wrote the code and rewrote the section the night before the beta went out, and even tweaked a screenshot the next morning. Move fast and break stuff, I guess.

Two chapters left: Extending Xcode has been in the can for months, Testing still needs to get written. Not sure which one they’ll ship next, but we’re almost done now.

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.

The types to represent blog entries and a feed, as well as the JSON stuff, are the business logic of the app, and they are in a “common” group. These files are 100% compatible between macOS and iOS, being based on the Foundation framework and the Swift Standard Library.

The trick is just to use the “target membership” checkboxes in the File Inspector to have them build for both platforms (in this example, I put all supporting files in frameworks, so they build as part of either an iOS private framework or macOS private framework). You could also add them with the plus button in the Build Phases tab of each target’s settings.

There’s also a view model class that represents the blogs to be shown, which has a delegate it can call out to when the contents update. This is trivial, and barely an example of MVVM, but it allows me to keep even the view models cross-platform — all that the platform-specific view controllers need to do is to implement the delegate method and update themselves. In practice, this actually ended up being identical between platforms as well:

extension MasterViewController: BlogFeedPresenting {
  func blogFeedViewModelDidUpdate(_ model: BlogFeedViewModel) {
    DispatchQueue.main.async {
      self.tableView.reloadData()
    }
  }
}

I also made a quick one-off video walking through the project:

Finally, I don’t want to make this sound like news. It’s really not. It’s just using Xcode targets as they were meant to be used, something that just seems to have been overlooked a lot.

Iirc, Apple only has one WWDC session on sharing code between iOS and macOS (back in 2014) . How come they didn’t bang that drum every year ?

— Jimmy Coyne (@jimmycoyne) June 18, 2018

Huh. Our apps would be twice as hard to maintain if we didn’t do this. I kinda assumed everyone knew…

— Liz Marley (@emarley) June 18, 2018

I was thinking the same thing. But then I tell people we build 3 SDKs from 1 workspace and people go “wow”. Another idea for a talk, maybe?

— Ben Scholtysik (@Elektrojunge) June 18, 2018

Anyways, there’s also an example of this coming in what should be the next update to Xcode Treasures, but that example is about adding tvOS to an iOS project, and I wanted to get a Mac example out there too. This took about three hours to write, evenly split between business logic, iOS UI, and macOS UI.

Anyways, point being: this is totally doable. No, it’s not just a checkbox, because it assumes you would want some level of control over what your Mac UI looks like and how it works. Y’know, like you care what you’re doing, and how your users experience your app.

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.

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.

The Argument For

So, the case for Marzipan (that’s the code name that came up in all the rumors earlier this year, and what everyone understands, so let’s go with it) is something like this: there are a lot more iOS developers than Mac developers, and they’re writing code that is this close to working on the Mac. Simplify that process and you get a flood of Mac apps for free.

Another version of this argument is phrased as a criticism of macOS’ user interface framework: AppKit is too hard for developers coming over from iOS, it’s too different, it has crappy old legacy stuff that’s waved off as “you had to be there”. NSTableViews don’t work quite like UITableViews, NSViewControllers aren’t exactly like UIViewControllers, and so on. It’s too off-putting for indie developers, and an unwanted expense for corporations to have to find and hire developers who know and like AppKit.

Side-Eye

Maybe I’m not bringing sufficient enthusiasm to the argument in favor, but the above is pretty much it, as I see it.

And this is where I jump off the Marzipan hype train. Because the above is an argument in favor of laziness and cheapness, which are two things we do not typically associate with developing for Apple platforms.

Is it really that hard to share a codebase between Mac and iOS? I just sent off the “other platforms” chapter of Xcode Treasures, and one of the sections is about creating multi-platform projects. The book shows how to add tvOS to an iOS project from earlier in the book, but the idea is the same regardless of which platforms you support: portion off the code you can into cross-platform frameworks, ideally leaving only platform-specific UI code in each platform’s targets.

This is more plausible than you might initially realize, because the platforms share a lot of code under the hood: Foundation, Core Location, StoreKit… these are all on iOS, macOS, and tvOS (and some are even on watchOS). Even the underpinnings of the UI are cross-platform: Core Graphics, Core Animation, Core Text, AV Foundation, etc., all exist across the Apple platforms. That’s why it makes sense for the documentation sets to have merged a few years ago: you don’t need four copies of NSURL docs when it’s the largely same thing everywhere.

Yes, you would want to be thoughtful about how you architect your code so it builds and runs on all these platforms. 10,000-line view controllers are going to be much harder to port than small, embeddable VCs, where you’ll have more control over which to put in their own windows versus embedding in parent VCs, etc. (Dave DeLong’s A Better MVC is a crucial guide here). In fact, I’ve found that using embedded VCs is also critical to making apps that work well on iPhone and iPad — it gives you flexibility with scenes that need a full screen on the phone but maybe could be part of a bigger scene on the tablet.

I can also imagine an MVVM approach being good for a UIKit/AppKit hybrid, because the logic you put in the view models would likely be fairly cross-platform, leaving just platform-specific code remaining in a small view controller.

But here’s the painful part: the techniques to do these things are already available, well-known, and very few people are using them. There are still lots of iPhone-only apps, or apps that make poor use of the iPad and just let their table views stretch out to infinity. And as for tvOS… it already runs UIKit. Your scenes are actual damn UIViewControllers. And yet look at the dearth of TV apps. We’ve had Marzipan on the TV for years and almost nobody uses it.

That’s something that makes me skeptical about the Marzipan dream. Developers who give a crap are already able to make this kind of thing work, and developers who don’t give a crap aren’t going to do it no matter how easy you make it.

IIUC, Twitterrific builds for both macOS and iOS from the same code-base, and the IconFactory is a small shop. But maybe that’s the point: it’s made by a small team that knows, cares, and enjoys what they’re doing. Exactly the kind of people that make the best Mac and iOS apps. Exactly not the kind of people you target a cross-platform framework at.

Repulsed by Electrons

To be clear, the enemy is not other Apple-platform developers. The enemy is the use of bloated, cross-platform, phone-it-in frameworks. “Write once, run everywhere” has been promised and come up wanting for decades: Java applications and applets, Adobe AIR, Xamarin, PhoneGap, and so on. One semi-success story of recent years are the various approaches like Electron and Chromium, which effectively embed an entire instance of the Chrome web browser in an app wrapper. This approach is used by such Mac apps as Slack, Discord, and Spotify.

It is also a goddamned scourge, and straight up an abuse of the end-user’s equipment.

See, that's what makes me mad. I think developers who use those are literally *stealing* the functionality that their users paid for. It's like saying "I have a greater claim to your CPU and RAM, and that is that I'm too lazy to learn native languages & APIs."

— Chris Adamson (@invalidname) June 1, 2018

But here’s a thought: is this approach popular because writing webapp code is inherently easier or more productive? Or is it the value in the fact that the webapp code has already been written — for the web page — and this just gives it a suitable environment to run in?

Because in that case, screw the app, you might as well just run the web version:

Here’s a thought: save 1.5 GB of RAM by quitting the “native” Slack and Discord apps and just run them in the browser instead. #ElectronSucks pic.twitter.com/KR78ByNfDp

— Chris Adamson (@invalidname) June 8, 2018

And this is something that not a lot of us probably want to admit, but a lot of iOS apps are de facto replacements for webapps, and make sense on mobile primarily because of the limits of mobile web browsers and the impracticality of juggling lots of open tabs on the phone.

Back in my Java days, author Bruce Tate’s Beyond Java raised hackles by exposing an unpleasant truth about web development: most of it consists of connecting databases to web pages. Well you know what, a lot of iOS apps consist of connecting databases to UITableViews. The presentation ends up being different, but the concept really isn’t.

In fact, look at the four Marzipan apps being included with macOS Mojave: News, Stocks, Voice Memos, and Home. The first two of those are basically web pages.

In fact, they may not even be as good as competitive web pages. If you’re interested in stocks, and you have an online broker, aren’t you going to be better served by the Charles Schwab or Ameritrade page, which will have not just price data but access to your account? Is the News app really competitive with the wealth of news websites? And what is it about being double-clickable apps that gives them any kind of advantage over web pages?

How many iOS apps out there are basically duplicating web pages? What’s the advantage of a Netflix or Hulu macOS app over their web page equivalents? In many cases, their current iOS apps have less functionality than their web versions: you often can only manage users and queues in the web version. Or consider how the Pandora iOS app is basically playback-only: if you want to create a new custom station, you need to use the web page. Why would I want the minimally-functional iOS app brought to macOS, when a more functional equivalent just requires popping open a new Safari tab?

The web is all about content consumption. That’s what browsers, not apps, are for.

Sure, there are exceptions, because some iOS apps do real work (Overcast would be an obvious example). But for the most part, I have a hard time thinking of iOS apps that I wish I had on my Mac.

Anyone keen on replacing their Steam game collection with free-to-play games from their phone? I thought not.

Share and Share Alike

One more thing: macOS development has a ethos of completeness and interoperability that doesn’t exist on iOS. Any Mac app worth its salt supports copy-and-paste and undo-redo, but in my experience, these features are rare in iOS (beyond the degree to which they’re provided by system UI widgets). In fact, I used to do a conference session about copy/paste and undo/redo, framed as an “80’s flashback” because it feels like the secrets of these APIs have all but been lost to time.

If I start seeing Mac apps where Edit > Undo is grayed out, and cmd-C does nothing but beep, those apps are likely going straight into the trash.

The Future!

The thing is — and this proves how crappy a Cassandra I am (and how I don’t have access to any big-time secrets) — when I first read the Marzipan rumors, I assumed they were a misreading of a more interesting, more ambitious project.

Because if I were a software architect looking at these platforms, I’d be pretty frustrated by the cruft, and in particular how the frameworks are unable to take advantage of new programming languages and paradigms.

I had a rant in a now-lost micro.blog reply I sent to Daniel Steinberg, the gist of which is how there are four paradigms for asynchronous events in Cocoa and Cocoa Touch, and three of them are poorly-suited to Swift. Key-Value Observing requires that the observing object subclass NSObject, and implement observeValue(forKeyPath:of:change:context) (a method that necessarily becomes a switchboard once you’re observing more than one key path). Target-action and delegation both require dynamic dispatch: either as storing a selector to call on the target, or to look up whether the delegate implements a given method. That’s great for Objective-C, less so for Swift.

Thing is, both of these languages now support executable code (and captured scope) as a type: Objective-C blocks and Swift closures. That’s why all the new frameworks tend to use handler-style APIs: you pass in a block to be executed when something interesting happens (a task completes, a timer fires, etc.). This last style is the most familiar to developers raised on onClick and leads naturally to modern styles of programming, like the RxSwift that’s so beloved by hipsters.

I can totally see a future UI framework that unifies UIKit and AppKit in a form that makes much more sense for Swift than either does today. That’s something to get excited about. It could be a long way off, if it’s even in the cards at all.

But in the meantime, the prospect of zero-effort iOS ports doesn’t sound like it’s going to bring a lot of value to my Mac. It’s fine that Apple’s doing it, but for the time being, the Marzipan hype train just gets a shrug from me. And if I do feel the need to get moving on a Mac app — I keep thinking about making DVDivvy a real app now that QuickTime’s days are numbered — there’s no question I’ll go directly to AppKit to do it.

To be honest, this could well have been called The Git Chapter, since Xcode’s protocol-agnostic source control features are dropping support for Subversion, leaving Git as the Highlander-style there-can-only-be-one winner.

And to be even more honest, this chapter more than any other owns up to limitations in Xcode. Our IDE of well-we-didn’t-really-have-a-choice doesn’t offer every Git command, and doesn’t even try to. Some commands, like bisect, would require an entirely different UI to implement, and the hard-core history-rewriting commands like cherry-pick and rebase are apparently above Xcode’s pay grade.

So what’s the point? In practice, a lot of developers do use Xcode’s Git support… in addition to using some other system like the command-line or the GitHub app. Some people use Xcode’s nice UI for doing visual diffs; others do simple commits in Xcode rather than losing their momentum by switching apps. The chapter gets into the features you might decide to pick and choose.

Also, it has one of my editor’s favorite jokes/references in the whole book (it’s either this, or the “duck season / wabbit season” joke back in chapter 6):

And, for those of you who end up outside of Xcode, there’s a section on how to resolve conflicts on the command-line with /Applications/Utilities/FileMerge:

To top it off, there are even some tips on resolving merge conflicts in project files and storyboards, along with some finger-wagging about better development practices that would have kept hypothetical you from having a storyboard merge conflict in the first place (but, yes, you can make sense of the storyboard XML and resolve a merge conflict by hand if you’re brave… I’ve actually done it myself a few times and I’m not dead yet).

As I dug into the material again — we did cover code-signing and App Store submission in iOS 10 SDK Development and its predecessors, after all — it turns out that the approach of this new book really helped out. After all, everything Xcode touches is fair game, so I could start with a simple Mac-only concept: sandboxing. That lets the chapter start of with a simple introduction to the current target’s capabilities tab, before getting into the whole kielbasa of iOS code-signing and App Store submission.

After a simple look at local-only sandbox concerns, things actually fell into place for a coherent narrative. Go beyond sandboxing and you find that there are capabilities like push notifications and iCloud that touch Apple’s backend or the user’s private data, and therefore require entitlements. And to deal with entitlements, you’ll need an AppID that specifies your entitlements, which you manage at https://developer.apple.com/account.

And when you find the AppID in the “Certificates, Identifiers, and Profiles” section, you’re already on top of the other two parts of the equation: the profile that will connect an AppID to a permitted action like installing on a development device or distributing via the App Store, and the certificate that you use to sign it, thereby proving your identity to Apple and ultimately your end-users.

Xcode’s automatic signing helps to teach this stuff, because you can let it generate all of these for you automatically. It makes it much easier to get to the final step, which covers manual signing. That’s a pain, but it feels like having made the journey there step-by-step, you can see how the pieces fit together, and take care of it yourself (if you must).

It really helps that my editor, Tammy Coron, is also an Xcode user and has had to deal with app-signing struggles, so she was able to make sure the line through this material was clean (she had me rearrange some stuff where AppIDs get introduced), and pushed me to really justify manual signing in the era of automatic signing.

The other thing that helped this fall into place was re-titling the chapter “Security”, although at first that’s misleading. This isn’t entirely about Xcode keeping you secure. By and large, these systems exist to protect Apple and its users from you, or at least someone pretending to be you. It doesn’t feel great to have to jump through hoops and show your bona fides to get your app up on the store, but it’s not unjustified either.

And honestly, it’s a hell of a lot better than it used to be. For me, the biggest improvement has been that you can have one development certificate per machine, rather than per account. In the bad old days, you’d inevitably caught on your laptop with a bad configuration, have to manually revoke your old cert and create a new one, and then clean up everything when you get back to your desktop Mac. Multiple development certs, plus automatic signing, made this material a lot easier to write than it was five years ago.

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).

Targets

Let’s hold up: WTF is this book anyways? Is it a new version of the Prags’ introductory iOS 8|9|10 SDK Development book? Nope, we decided to something radically different this year, something for readers at different stages of their development.

Xcode Treasures is about Xcode itself, not about any of the SDKs. In fact, while the default mindset is Swift + iOS, the book contains examples for iOS, macOS, tvOS, and watchOS, written in Swift, Objective-C, and even plain ol’ procedural C. The idea is, I’ll use whatever form best suits the topic at hand. Want to see how the Address Sanitizer works? You’ll need to write some crashing C code for that. Interested in Auto Layout? I think you get the gist better by making a Mac window with Auto Layout and resizing it yourself: you get real time feedback on how your constraints are being applied.

None of the examples are so hard or so deep that you can’t at least get the idea of what’s going on, even if it’s out of your usual wheelhouse. And if it inspires you to try out one of the other Apple platforms or languages, better yet.

Because the thing is, the real goal of the book is to come to a deeper understanding of Xcode itself. Think of how you usually use it: you start with a template like “Single-View App for iOS” or “Metal Game for Mac”, or “TVML App” and it’s all set to build and run as-is, even with no functionality. Then you start adding code and art. And sooner or later, you find that you have some sort of unusual or advanced need, and maybe you can’t figure it out because all the time you saved by starting from a template rather than building a project from first principles meant you never had to see how Xcode really works.

At this point, maybe you conclude that Xcode is dumb and can’t do what you need, when really you’ve only ever used 10% of what Xcode can do, and there’s not a clear path to see how the other 90% works.

Preferences

Doing something different than the usual beginner book was one of my inspirations for writing this book, but there was another: I want to answer the sort of lazy cynicism that has emerged about Xcode in some developer circles. So much of social media rewards takedowns and hot takes, so you can always collect social status just by ripping on Xcode. Problem is, newcomers to development on the Apple platforms see this and emulate it as a means of elevating their own status within the community. Of course, that’s not specific to Apple developers: if you want instant street cred among anime fans, just tweet “Sword Art Online sucks” and everyone will tell you how right and good you are. Same goes for throwing around the term “late-stage capitalism” like you are genuinely credentialed to predict the future of world economics. Dump on stuff and people will reward you for it. Even as a life-long pessimist, I’ve grown tired of this racket.

The book’s working title was No Regrets Xcode, and at one point, I toyed with proposing Xcode for People Who Hate Xcode as a title. But a full-throated defense of Xcode is an essay or a blog, not a programming book. Instead, I hope to prove by example — many, many examples — that Xcode is better than you think it is.

Now, I’m not blindly loyal either. I see all those 1-star reviews for Xcode on the Mac App Store. And one of my tech reviewers pointed out that despite my cheerleader-y tone, he has filed hundreds of bugs with Xcode, and I’m sure they’re all valid.

My argument is this: to me, Xcode is indeed plagued by the same reliability problems that affect most Apple software in the current era (c.f., Marco Arment’s Apple Has Lost the Functional High Ground). It’s worse because we as developers depend on Xcode to get our work done. But how do you think people who depend on the Pro video apps feel right now? High Sierra has a been a disaster for them, and as just a part-time video guy, I’m often hobbled by lock-ups in Final Cut Pro, or this insane bug in Compressor where output files were many times larger than configured, but only on the 2013 Mac Pro (I was not happy about this one). And let us not even speak of iTunes and its myriad problems.

So, yes, Xcode is flawed. But is it fundamentally flawed? Is there some core concept — its multi-paned single window UI, its scriptable build system, the nature of app bundles and code signing — that makes it impossible for Xcode to ever be good? I don’t believe anyone is making this argument. The closest you get to this is storyboard haters who build their UIs in code. I disagree with that camp, but even if I didn’t, that alone is not enough to relegate all of Xcode to junk status.

Connections

So yeah, I’m playing a contrarian game here. That’s why the cover of the book is such a wonderful design that everyone fell in love with when we saw it. On the one hand, gold + apple. But it’s also the Golden Apple that goddess of discord Eris used to spark an argument between rival goddesses and, ultimately, lead to the Trojan War. With all the arguments about Xcode, what better thing to put on the cover than the literal icon of strife?

But I’m also reminded of another contrarian play. MacAddict magazine launched at the nadir of the Mac, in September 1996, when the Mac was getting walloped by Windows 95. And yet look at the cover of the first issue: “Why the Mac’s future is bright”.

And you know what, they were right. Even despite the fact that not only were the financials bad, but the Mac itself had a lot of problems: this was the era of Type 11 errors destroying all your work, and software companies goosing their stock price by publicly announcing they were dropping the Mac. In fact, this first issue even has a cover feature on how great OpenDoc is, even though OpenDoc turned out to be a software architecture wrong turn that eventually fizzled out.

MacAddict worked because its writers, editors, and readers knew that if you looked past these problems, the fundamental vision of the Mac as a tool for creation and communication was far more compelling than the Corporate Obedience mindset that Windows offered.

So, I’m making the case that it’s time to take a fresh look at Xcode. Acknowledge the bugs, sure. Hope that they get better. But beyond that, look at how nice the code editor is (and how you can customize it to suit your own tastes). Look at how the build system is smart about resolving dependencies, how you can set up your own build properties on a per-configuration basis or even run arbitrary scripts during the build, or run the whole thing from the command line and let Jenkins handle your CI. Think about how app slicing and on-demand resources make things better for your users by making smarter use of their limited on-device storage, and how Xcode gives you a UI for managing these assets visually. Behold the wonderfully clever power of LLDB to give you powerful breakpoint capabilities, and tools like Instruments, Main Thread Checker, Address Sanitizer and more.

Build and Run

The beta book launching today has 7 chapters. Three more are fully written and will roll out over the next few weeks. Two more are still being written. After incorporating errata fixes and other feedback from readers, this should result in a final book in August or so. With books from the Prags, I always advocate getting the eBook or an eBook-plus-paper bundle directly from the Prags, because you get updates, and it includes all the formats you’d need: ePub for iBooks, .mobi for Kindle, and PDF.

[Update: Currently, only the ebook is available, because they can’t charge for something that won’t ship within 30 days, and the print edition is further out than that. ebook buyers will get a coupon offering upgrade pricing to the ebook + print bundle when it’s ready. Details on the Prags’ Beta Books FAQ.]

The book’s home page also include three samples that you can check out for a taste of what’s covered. It was hard to pick, but I went with embedded scenes, code snippets, and build phases. All of these contain tricks and techniques you can apply to your own work right away.

I’m also really fortunate that editor Tammy Coron is also a long-time Xcode user, so she’s able to give me detailed feedback and have a fresh set of eyes on where the material does and doesn’t flow well, is and isn’t helping. Along with a lot of tech reviewer feedback (some of which I’m still working through), that’s making this a better book.

Hopefully you’ll all enjoy this deep dig into the depths of Xcode!

The immediate and obvious takeaway is the significant contraction in this space over the last two years. By my count, the US now has only 9 conferences that are exclusively for iOS/macOS developers (in approximate chronological order for this year):

• Forward Swift
• Teki-Con
• RWDevCon
• 360iDev
• WWDC
• AltConf
• Swift by Northwest
• Swift Summit
• try! Swift NYC

I say “only” because it was only about 4 years ago that CocoaConf ran more conferences than this by themselves in a single calendar year. And now, CocoaConf itself is gone; its organizers, the Klein family, run a single annual conference in its place, Swift by Northwest. The remaining conferences are almost entirely held on the coasts in cities like NYC, DC, and of course SF. Only one is in the South, and none are in the Midwest, Texas, or the Southwest.

[It should also be noted that in some years, Apple runs a world-wide traveling series of “Tech Talks”, often when they have a new platform to build support for. The last one was in 2015, and promoted the Apple TV SDK.]

In my spreadsheet, I use the event type “later” to denote a conference that is expected to be held in the next 12 months but doesn’t have a date yet, and “defunct” for conferences I believe will not be held again. As I said on Twitter, my criteria for defunct is “no events held in the last 12 months, and none scheduled as of now”. By that criteria, this is my list of recently-defunct Apple developer conferences:

• 360iDev min
• CocoaConf
• CocoaLove
• DO iOS
• IndieDevStock
• NSConference
• NSNorth
• NSScotland
• Playgrounds
• Úll

I didn’t include Release Notes on this list, because their most recent podcast episode made it clear that while they are not holding a 2018 event, they aren’t piling it in either; it sounds like they want to shift the time of year they hold their conference. Daniel Steinberg also tweeted at me to say that both Do iOS and NSNorth have said they hope to return, and similar sentiments are expressed on the home pages of IndieDevStock and Playgrounds. So, you know, maybe they’re not all dead.

[Also, I’m not interested in tracking conferences that went away many years ago and will obviously never return, which is why I don’t bother with an entry for Voices That Matter: iPhone Developers Conference from seven years back or the O’Reilly Mac OS X Conference from 15 years ago.]

For the sake of keeping things interesting, I do track a few conferences that are “close enough” to be of interest to this community, like conferences for IT pros (Mac Admin & Developer Conference UK, MacAdmins), Mac power-user events (MacStock), and did you know that there’s actually a conference just for Filemaker developers? Because there actually is a FileMaker Developer Conference. This variety is nice for the video scroll, which I use as an interstitial when I’m livestreaming, so I can give my voice a break.

But still, I think it’s interesting to note that there’s been an obvious, substantial contraction in the conference scene. Some of the survivors seem to be healthy (Ray Wenderlich says RWDevCon is nearly sold out), so is there any way to make sense of what is and isn’t working here? A few thoughts…

iOS Is Old News

The obvious explanation is that after 10 years, iOS is old news, that most people who want to work with it are already doing so, and there’s less travel/training money available. This makes sense, to a point, although if that’s the case, then how can the No Fluff Just Stuff tour be doing 17 events this year, hawking old warhorses like Java and Spring?

Still, the idea that iOS is old and unsexy can be seen in the fact that nearly every new conference focuses on Swift, even putting it in their name: dotSwift, try! Swift, Forward Swift, Swift by Northwest, Swift Summit, etc. Good for marketing, although as a speaker, I find it somewhat limiting: I don’t feel like I could do a talk on, say, debugging with Instruments or Auto Layout in storyboards, since those wouldn’t really be about Swift. One reason I’m not planning any talks this year is that I just don’t have anything novel or insightful to say about Swift at the moment, since I’m not currently working with it as much as a lot of other people are.

Apple Development Is A Cargo Cult

Every conference is completely overshadowed by WWDC. It used to be that nobody wanted to hold a conference between June and October, because the new bits at WWDC would still be technically under NDA, so you officially couldn’t talk publicly about them. That meant that anything you could talk about was, by necessity, old news, which made an August conference a hard sell.

Today, WWDC is nearly impossible to get into, and all its videos are quickly made available to non-attendees (lately, most or all of them have been livestreamed). So if you’re just interested in getting Official Info from Cupertino, just standing in front of that firehose is all that’s necessary.

And honestly, that’s what most people want. If you see the platform as just a collection of APIs, tools, and languages, you could make the argument that third parties aren’t in a position to bring anything else to the table. It’s not like there are very many third-party tools that most iOS developers use — Cocoapods and Carthage, I suppose? Maybe SwiftLint? God forbid, RxSwift? But mostly it’s about the built-in bits. So if you can already get a session of those, why travel for something else?

[Well, I’d argue things like clarity, novelty, and honesty: speakers with real-world experience can talk about how the APIs hold up in real life or if they’re not as good as Apple says, they can offer insights into more advanced uses or unanticipated issues, they may be able to offer more passion and excitement than WWDC engineer-speakers, etc.]

Few Personalities Can Sell Seats

Another factor is whether or not people will come to see specific speakers, and who they are. Who’s really famous in iOS/macOS developer circles? It’s not like we have a lot of open-source projects with leaders that everyone follows. A lot of the conferences rely on book authors (like me), but book sales continue to decline, so I don’t suppose we’re much of a draw.

Bloggers? John Gruber of Daring Fireball speaks infrequently, such as at the 2014 XOXO Festival, and of course in his live episode of The Talk Show every year during WWDC week. I don’t recall if Michael Tsai (whose linkblog is essential reading) ever does conferences, and I’m drawing a blank on other notable names.

Podcasters? We’re doing a little better there. Daniel Jalkut and Manton Reece of Core Intuition have both spoken at various conferences (including CocoaConfs in DC and Austin). OTOH, the Accidental Tech Podcast guys are infrequent speakers: I recall Casey Liss keynoting a CocoaConf DC, and Marco Arment recorded an Under The Radar at CocoaConf Next Door during WWDC 2017 week, but that’s about it. OTOH, Curtis Herbert of Independence speaks at several conferences, and was the organizer of the CocoaLove conference. Yosemite by CocoaConf used to always have Andy Ihnatko, but that conference appears to be done too.

Is Staying Home An Option?

Part of the problem with conference-going is that it’s damned expensive. Even if a conference keeps registration under four figures, big city hotel stays will often cost far more than the conference ticket, plus airfare and meals. You have to really pinch pennies just to keep a week at WWDC under $4000. That was one of the things I liked about CocoaConf: they toured and came to where the attendees were (so you could maybe drive to it), and they generally set up shop in inexpensive airport hotels rather than pricey downtown locations.

For international attendees, border crossings are also a hassle and risk, particularly given the ugly xenophobia that is now official US policy. It’s understandable that overseas developers would think twice about coming here (or, for that matter, that non-US nationals working for Apple would risk leaving the US for Tech Talks, since they might well not be let back in).

And when you think about it, if most people in the world are experiencing WWDC on a screen, maybe that’s the way other conferences should go too.

This weekend, I attended Visual;Conference, a seven-hour online webinar for developers/writers/artists working on visual novels. The presentations were all streamed via GoToWebinar, with back-channel chat and questions to speakers handled by a Discord channel. For $10 I got to participate, hang out in my slob clothes, have a beer and nachos for lunch, and still learn about the iOS app that makes $1 million per day.

Videos from Visual;Conference 2018 are available as a playlist from the conference’s YouTube channel.

Maybe we can bring these worlds together. Not that a WWDC session is ever going to begin by saying “Spoilers for Doki Doki Literature Club, everyone…” (though wouldn’t that be great?), but maybe someone should give an online iOS/macOS conference a shot? It might be particularly good for a niche topic that maybe only 50-100 people in the world are going to be interested in. Although even with this approach there are problems with time zones, since you aren’t bringing speakers and attendees together physically — Visual;Conference started with its Japanese speakers at 11AM ET / 8AM PT, even though this was 1AM for the speakers Japan-time, and they were gracious staying up that late for us. If you wanted to hold an online conference open even to just Europe and the Americas, it’s going to be either too early for someone, too late for someone else, or both.

Honestly, I’d rather have CocoaConf back, but since that’s not happening, and there is literally not an Apple developer conference within a day’s drive of me this year, I guess I’m stuck.

Sort of as an experiment — and also because I needed ready-to-go content for my weekly livestream — I decided to go through the entire iOS 10 SDK Development book that I co-wrote with Janie, in 30 minute chunks at the beginning of each week’s stream, prior to getting into the fun stuff like the iPad let’s plays and the visual novels. The Xcode segment was fairly easy to prep each week, it got me back in touch with the contents of the book and what I do and don’t like about it, and being all in XCode, it was a different way of presenting the material than several paragraphs of thinky-think followed by a code listing.

Oh, and as a bonus, it allowed me to create a complete intro-to-iOS-development video course.

The Prags have been publishing links to each video as I get them up on Vimeo, on the book’s home page, and last week, I finished the book. So if you’re so inclined, you can start watching all 24 videos, even without a copy of the book. Heck, you can even download the code from the book’s home page.

And yeah, I know, it’s “iOS 10 SDK Development”. Actually, I was pleasantly surprised that nothing broke during our year away from the book. If I had to update it now, I’d want to cover the Safe Area in Auto Layout instead of just talking about margins, and of course I’d get in some iPhone X screenshots, but that’s about it. (There are other topics I’d want to cover, but what’s there now isn’t incorrect or anything.) We’re pretty lucky that we moved the book’s sample code away from Twitter and turned it into a podcast app instead, because all the Social framework stuff that we depended on for the iOS 6 through 9 books is gone in iOS 11. We totally dodged a bullet there.

So anyways, help yourself to the videos, either on the Prags page or invalidstream.com. I’m taking a couple weeks’ hiatus from the stream to speed up work on my next (unannounced) book, and to build up the content pipeline for another few Friday nights of Xcode work, non-F2P iPad games, and Muv-Luv Alternative (we’re almost to where it gets good!).

Following Apple’s clarification that iPhone 7 and iPhone 8 models do not have FM radio chips or antennas designed to support FM signals, the National Association of Broadcasters (NAB) has expressed some doubt about Apple’s statement and has called on the company to add FM functionality to its future iPhones.

[…]

In its blog post, the NAB appeals to Apple CEO Tim Cook, highlighting the number of hurricanes experienced in Mobile, Alabama, Cook’s hometown, since 1969, and calling on the company to introduce FM support as a way for customers to get news alerts during disasters.

If your concern is access to news during disasters, may I suggest concerned families simply buy a dedicated portable AM/FM radio? Among its advantages:

• Such radios start at under US$10, and the product line as a whole is 1 to 3 degrees of magnitude less expensive than iPhones.
• AM/FM radios last longer on a fresh set of batteries than iPhones do on a charge, and can be recharged indefinitely during a power outage, so long as more batteries are available.

It’s a sad scene between this and the FCC Chairman cluelessly calling on Apple to magically activate FM features that either aren’t physically connected or don’t exist at all.

It also speaks volumes that the NAB needs to rely on either national disasters or Federal bullying to get broadcast radio devices into the hands of consumers. Usually when consumers are forced to buy something, it’s a pretty good sign that what’s being sold is crap. Try listening to US terrestrial radio — dominated by ClearChannel bots playing the same songs over and over, and asshole blowhards going on hours-long conservative rants — and it’s little surprise that fewer Americans have any interest in the technology anymore.

No wonder the NAB wants to ride piggy-back on Apple’s popularity and the hundreds of millions of iPhones out there. But I think they ought to get their own house in order first, before they start talking crap about Apple.