I'm usually pretty good at inferring where Apple is going with their projects and products. With Swift, I'm left shrugging. Hopefully the purpose of Swift and how it relates to Apple becomes less muddy next week.
Since 2004 (!) I have been attending WWDC on a regular basis. My first time was on a student scholarship thanks to some incredibly poorly written Objective-C code back in the Mac OS X Panther days. Fast-forward to 2017 and we've gone from Apple the underdog computing platform to Apple the juggernaut that has four top-tier platforms.
After you've attended a handful of WWDC's, you start to realize the pattern. Unlike a conference like TED which explicitly puts the theme of the event on the cover, WWDC is a bit more subtle. If you attend enough sessions you start to realize both what Apple is interested in this year, but also in this new iOS era, where they are skating towards in the fall.
Skating to Where the Puck Is Going
When Apple introduced Auto Layout with iOS 7, they started pushing the idea of having both iPhone and iPad apps being built from the same core interface elements with minimal additional effort by the user. It was also a pretty good hint that Apple had their eye on a larger iPhone, someday. When size classes were introduced with iOS 8, they were literally beating you over the head saying larger phones were coming.
Size classes were an important announcement in 2014 with iOS 8, but the biggest announcement was by far the introduction of the Swift programming language. Though not marketed as an absolute successor to Objective-C, most have taken the introduction of Swift as a pretty good indication of where Apple wants to take software development for their platforms for the next decade or more.
With Swift, Apple gave themselves a clean slate to build a modern language for mobile development, without the legacy of a programming language that was designed for NeXT Cubes in the 80's. Swift checked many of the boxes that new and old Apple developers had been clamoring for by offering things like static typing, optional types, and not having to think about pointers for the majority of mainline use cases.
Swift also infused a lot of new ideas into development on Apple's platforms. Subclassing began to be seen as a last resort when protocol-oriented programming and value types couldn't be used. A traditional
for loop was passé. Instead,
forEach were how you flexed your Swift muscles.
Living on the Edge
The first version of Swift was, dare we say, challenging and I avoided using it in production. With the release of Swift 2.0, the water seemed cool enough that the first bits of Swift code landed in production at the day job. In fact, most of the new code being written at that point was in Swift rather than Objective-C. The tooling still suffered from a lack of reliability and stability, but I kept reminding myself that I was using a new, rapidly iterating language and that just comes with the territory.
Swift 3 was the first release after the open sourcing of the language, and honestly where I think my love affair began to wane. After being open sourced, Swift started to feel like a language that stopped actually moving forward in ways that made sense to me. Removing traditional
for loops and increment/decrement (
++/--) operators were pushed through the Swift proposal process as improvements the core language by the fact that there were "better" ways to replace their functionality. From a theoretical perspective, that makes a lot of sense. Practically, I was left wondering why it was worth the effort when there are still real problems needing to be solved.
The biggest travesty was the "Great Renaming" which touched every line of Swift code I had and burned a week of my life on tedium. In my decade of professional development, I have never had a worse experience. The migration tool caused more issues than it automatically resolved, leaving a manual migration as the only sane path forward. How that migration tool ever made it through QA is beyond me, but I'd have felt better if Apple just said "good luck" instead of offering a half-baked utility.
One can argue that renaming every method API method to be more "swifty" was worth the headache. I even agree to a point, but I also don't believe Swift 3 dramatically improved my experience as a software developer, especially when compared to the effort to get there. In fact, most of the decisions made since Swift was open sourced have left me scratching my head as someone just wanting to use the language to write iOS apps.
Practicality vs. Ideology
I'm a practical iOS developer by day. I try to use a value type where it makes sense, but I also still design my table views the old fashioned way with delegates and data sources. I still use Core Data for persistence. And I still use KVO where it makes sense.
From the outside, it seems like important milestones like ABI stability continue to be delayed as Apple and its open source contributors continue to chase the dream of designing the most pure language they can. Removing "legacy" operators and arguing over access levels seems to have taken priority over actually moving Swift forward as a first class language for Apple development. The problem with that is that software development isn't pure. It's messy. I've never written a perfect line of code in my life. I don't plan to either. Fixing a language in post is obviously harder than pushing a new build of an iOS app, but chasing perfection is a fools game no matter what the project is.
As a production developer I need ABI stability because it prevents me from having to recompile my dependencies every time the language is upgraded. It will also hopefully allow me to shave 8 megabytes off my download by no longer including a Swift runtime in every release. My product managers need those 8mb for more analytics libraries! I'd rather Apple spent its time giving me a concurrency story along the lines of
async/await instead of looking for new ways to make protocol extensions useful in scenarios that just don't make sense for my shipping products. And for god sake, improve compile times. I only have one life. I'd like to spend less of it watching a progress indicator.
I realize that the tools team and the Swift team are separate, but its hard to separate the two when Swift's primary method of development is Xcode. Xcode's quality as a Swift development language has never been great with its constant indexing, opaque compile errors, not great typing auto-completion, and lack of refactoring support still. With zero insight into the inner workings of Apple, it still feels like the language hasn't been embraced nearly as heavily internally as it has been externally. If it was, I'd believe that Xcode's Swift-related issues would be resolved much quicker than they have been. The biggest pain points external developers face always seem to be resolved once they become issues internally at Apple. If Apple can't use Swift to build its frameworks or its internal products because ABI stability is missing, they don't see all the warts we do.
Apple's path with Swift doesn't seem to solve the problems I have as a day-to-day iOS developer. Instead, the language design focuses on implementing functionality that would benefit server-side Swift, Playground demos, and showy conference talks. If that's the goal of the language, I sure wish they'd come out and say it. Right now it feels like I'd have been better served by continuing on with Objective-C, which is still being improved in meaningful ways, rather than going all-in on Swift.
According to the transcript of the chat, Apple has a few different types of pro users it is considering:
- Video editors
- Music creators
- Graphic designers
- Engineers and Architects
Developers you say?
Craig Federighi: I think if you use Xcode downloads as a metric, it’s possible software developers are actually our largest pro audience. It’s growing very quickly, its been fantastic.
Sounds like me. I download a lot of Xcode builds. I am important!
I can’t speak to what the other five types of users need, but I have a pretty good idea of what I’d want as an iOS developer who uses a Mac every day. Not that anyone in Cupertino is asking me, but if they did I’d say this is my dream Mac.
Let’s assume that Apple is going to ship this new Mac Pro in 2018. Yes, they are being coy with the semantics of when it will be available (“It won’t ship this year”), but just for this thought exercise, it’ll be on my desk around WWDC 2018.
A Tower of Boredom
Despite the fever dreams podcasters are having about what Phil Schiller meant when he said the new Mac Pro would be “a modular system,” I have no aspirations or desires for a stackable, modular computer where I can add an external GPU or other parts I desire. All I need is a tower that connects to an external monitor. That’s it.
Make it look like the Cheese Grater if you want, or spend time designing something more modern and attractive. If I get a say in size, I’d like something along the size of the Power Mac G4. The Cheese Grater design was nice, but it was also a chore to lug around the few times I needed to move or rearrange my desk.
I think it’s safe to assume there’s no optical drive required in a 2018-era computer, so that should hopefully offer some space and weight savings. I don’t need a micro-ATX architecture. ATX is fine. Just maybe make it not weigh 40 pounds if you can. We are developers, not bodybuilders.
I know Intel has been having trouble of recent years and has taken to tocking more than it’s ticking, but I also don’t see AMD as a viable alternative for CPUs1. Ryzen is interesting, but I’d rather have Kabylake or Cannonlake Xeons.
In terms of speed, the reality is that I haven’t been hamstrung by CPU performance in years. What I need more than faster CPUs is more cores. The trash can Mac Pro got this right. My iMac maxes out at 4-cores. I’m going to want at least 8 for a Mac Pro. Anything more than that seems overkill for me personally, but I can appreciate others might need 12 or more.
What will I use 8 cores for? Parallelizing my compilation in hopes of speeding it up. Well, assuming these Swift performance issues are resolved before you ship this thing.
I know you backed yourself into a thermal corner with the trash can. That’s in the past. All will be forgiven if you just default to using a boring old PCIe video card from Nvidia or AMD. The GTX 1080s are what I have my eyes on for upgrading my PC desktop to. I’d gladly take one in my Mac Pro too.
I don’t need multiple GPUs personally. I’m just a software developer who doesn’t do any game work. I just want to ensure that I have the best GPU I can get when I buy this so that I can ensure that macOS performs as well as it can for a few years. No stuttering when I toggle Mission Control!
And speaking of games, I don’t play them on my Mac. This dream of the Mac ever being a best-of-class gaming platform is long gone. Linux on the Desktop has a better chance of succeeding than I do of getting Overwatch on my Mac day-and-date as PCs and consoles.
I only use SSDs at this point, save for Time Machine. I need the fastest write speeds you can offer me. I’d like to have the ability to mirror my boot drive using RAID for redundancy, but I’ll survive if I can’t.
What I do need though is room for more than a single drive. If you’re going to give me a modular system, I’m going to want to move my Time Machine backup internal and maybe even have separate drives for different virtual machines or operating systems. I’m not doing macOS development right now, but I remember the times of having to boot up an old version of the OS to test or debug a release.
And if one of my drives does fail? I need to be able to replace it quickly, without sending it off to the Memphis repair hub.
I know you all love DDR3, but DDR5 is a thing now. Please? Lots of it. I can get by with 16GB of RAM on my laptop and the world goes on. If I’m going to buy a new tower that I expect to last for several years, I’m going to need at least 64GB of RAM. I’d take more if possible though! I prefer to not think about paging by throwing money at the problem.
What am I using all this RAM for? I don’t necessarily need it for building my app in Xcode, but when you add the virtual machines I run in Parallels for testing, Docker containers, and how the dozens of tabs I keep open at any given time it adds up. Slack also eats memory. I know you aren’t allowed to use it at Apple, but out here in the real world we do and it is a memory hog.
Adapters may be fine for not including Ethernet on a MacBook Pro, but I keep my desktops connected to Ethernet at all times. I need the fastest possible speeds afforded by my Internet connection for downloading and uploading things like Xcode releases, builds to TestFlight, and other bits and bytes I see fit. The current Mac Pro has two. I only use one, but I won’t lose sleep if you give me two.
Please include WiFi for things like Handoff and Airdrop, but don’t take away my Ethernet port for my primary Internet connection. I rely on it on my iMac and I would rely on it for my next Mac Pro as well.
Ports of Connection
I think it’s safe to assume that a developer’s Mac Pro would have the following connections:
I’d like to have a USB-A port or two to connect my wired, clicky keyboard, but I can understand if you don’t want to include them. I’ll add an adapter and never think about it again.
For the ports you do include, I need lots of them. I tend to keep an iPhone, iPad, and Apple Watch connected to my desktop at all times for deploying to via Xcode. I’d hope that without the space constraints of a laptop, every port has the same sort of bus speed. I don’t want to have to think about the upper-left USB-C port being faster than the lower-right one.
Modern Apple is defined by how locked down the system has become. That’s fine for an iMac or MacBook Pro, but I need the ability to swap out a few non-core parts in the future.
- Upgrading to a bigger / faster SSD as technology improves
- Adding more RAM if I can’t afford to max it out at purchase.
- Replacing / adding a new GPU card.
If you don’t want to support them via AppleCare, that’s fine. That shouldn’t negate my ability to extend and improve my desktop tower, however.
Apple computers are known for being quiet by default. I’m fine with the fans cranking when I’m processing a heavy load, but the default state should be minimal noise.
I know there is a new Apple Pro Display coming, and I’ll likely buy it. Throw a few USB-C ports on the back of it so I don’t have to run long cables from the tower on the ground to my desk. Maybe test it next to a WiFi router before shipping.
I have been using an iMac for the last few years because it seemed like a better option for meeting my needs of wanting a Retina Display with good enough performance. This new Mac Pro has the potential to send me back to Apple’s most niche hardware class. In fact, I’m funneling money away for this new Jesus Computer. I haven’t been this excited about the future of the Mac since the last time Apple said the Mac was back!
Sebastiaan de With pens what I consider to be the best argument for why Apple should care about a niche market of Pro Mac users:
Macs became the tool of choice of this new wave of designers, and as the web evolved Apple kept its OS and app ecosystem in sync with its trends; as online video became popular, Apple offered the easiest editing software in iMovie. Blogs and RSS had a peak; Macs came with iWeb that let you author blogs literally out of the box. These designers started to code, or came in contact with developers.
I was there for this, with both G5 and Intel variations of the cheese grater Mac Pro. Before Apple was the largest company in the world, they built the best computers and operating systems for the tastemakers of technology. I never worked with Seb on a project1, but I worked with some of the best designers that have gone on to build the biggest products of the mobile era. We'll ignore that I continue to toil in obscurity, dear reader.
I haven't said much about the Mac Pro's demise because there's plenty of other people with opinions on the hardware. That said, I am glad to see it's no longer on its deathbed. It may not be Apple's most profitable product, but it doesn't need to be. When you have the ability to positively effect the real influencers of the industry2, it's hard to see the downside. I am not sure if the Mac Pro is for me anymore, but I much prefer an Apple that invests at least some of its billions in flexing its computing muscle from time-to-time. Not because it needs to, but because it wants to and can.
(via Pixel Envy)
This is the latest installment of my must have must have list of tools and utilities as a macOS and iOS developer. The idea for this list was shamelessly ripped off from Windows developer Scott Hanselman whose list has long been an enjoyable read when he updates it.
There have been significant changes since I last did one of these. I’ve tried to mark anything new in bold.
Since I last updated this in 2013, my hardware has changed significantly.
I am still maintaining a dual Mac setup. My daily driver is a Late 2015 27" Retina 5K iMac with a 1TB SSD and 32GB of RAM. After nearly five years, I replaced my old 2010 iMac that was starting to show its age when compiling Swift. Swift eats hardware for breakfast, lunch, dinner, and fourth meal. I’d say this was Apple’s genius plan to sell more Mac hardware, but they can’t be bothered to update their hardware lineup regularly so there went that theory.
At home I am using my 15" Retina MacBook Pro with a 1TB SSD and 16GB of RAM. This is one of the new Touch Bar models and it’s fine. I somehow have been able to survive without a physical escape key or a row of function keys. I assume this makes me lose some sort of geek cred. Sorry, nerds.
I used to be a big Dropbox user, but I’ve moved all of my files over to iCloud Drive because it’s good enough. I take advantage of the Shared Desktop and Shared Documents functionality of macOS Sierra. Photos are stored in iCloud. Calendar and Contacts too. It works, usually. There wasn’t anything wrong with Dropbox, but it was just another thing I was paying money for that wasn’t super necessary when there’s a good enough alternative baked into the OS now.
In terms of accessories and upgrades:
- I use a Das Keyboard. I love it. The Das Keyboard doesn't make me a better developer, writer or person. It just feels satisfying to use.
- On the left side of my iMac I use a Magic Trackpad 2 for swiping and gesturing between full-screen apps and Mission Control. I am a big user of multitouch gestures in Sierra, so I am incredibly comfortable using the trackpad.
- On the right side of my iMac I use a Logitech MX Master to do all my pointing and clicking. It has more buttons than I have fingers, but somehow I have found a way to map a unique action to each one.
- Time Machine backups are handled by a 4TB LaCie d2 Thunderbolt 2 drive. It's fairly quiet and is one of the few external drives I've found that doesn't have a horrific design. The blue light has a piece of duct tape over it though because it was distracting.
- I connect to the Internet through my Netgear Nighthawk X8. It has four giant antennas on the back and looks like it may take off at any point. I am interested in trying something like Eero in the future, but for now the Nighthawk works.
I am really hard on software. This is for a variety of reasons, but I think it is because I build it myself. I have always envisioned that directors and actors can sometimes lose focus during a movie as they judge the decisions others made in their productions. I feel like I do the same thing with software. I loathe poor and/or non-native user interfaces and cherish simple tools. These are applications I constantly rely on.
The Essential Five
- Dash - I know Apple keeps trying to improve the documentation viewer that ships with Xcode, but I am still a loyal Dash user. Not only does it work with Apple’s documentation, but having other languages I may be using accessible as well is a big win.
- 1Password - One of the first tools I install. I store not only passwords, but also things like Amazon access keys, SSH credentials, and a variety of other things I need to secure with 1Password. Hopefully it’s more secure than the DNC email servers.
- OmniFocus - I don't know how I ever stayed organized before OmniFocus on my three screens. It's my brain. With my work tasks, I tend to take what I am currently working on and break it down into separate OmniFocus projects that I can focus on as a daily task. It’s easier than tracking everything in Asana or whatever bug reporter of the week my clients are interested in.
- Atom - The last time I wrote one of these posts, I was a devout Sublime Text user. Before that I was a BBEdit user. Now? Atom from GitHub. I use Atom for any non-Xcode related development tasks I have as well as looking at log files and other random bits of text.
- Tower - I can use Git via the command line if I have to, but I don’t see any reason to when there’s a powerful app like Tower there to do hide all the weirdness from me. I probably use this app more than any other third-party app on my Mac.
- Xcode - If you write macOS, iOS, tvOS, or watchOS applications, you spend most of your life in Xcode and Instruments. I am no different.
- Appfigures - Manually fetching iTunes sales reports is tedious. Appfigures is a low-cost Web service that will import your reports and send you a daily sales email. I also like to funnel our reviews into a Slack channel so we are more aware of what users are saying.
- Base - Core Data generates a SQLite database under the hood. I'm constantly inspecting the database contents using this application. It's lightweight and easy to use.
- Charles - Sometimes I want to snoop the traffic that is going through an iPhone app. Setting up Charles makes it pretty easy to do just that.
- Color Picker: Must have. Choose whatever color you want and then it will output a UIColor or NSColor for you.
- Git: I am now exclusively on Git for version control. Thanks, GitHub.
- HockeyApp - I am using Hockey for handling crash reports. Microsoft bought them a few years ago and continues to improve the service with other features, but I find the crash reporting to be the only indispensable function. At least until I can learn to trust iTunes Connect.
- Hyper - I am using more Electron apps by the year it seems. Hyper is a replacement for Terminal built on Electron. I don’t do anything special with it over the bundled Terminal app. I just like how it looks. I am such a Mac user.
- Kaleidoscope - I have never been a fan of the bundled merging tools with Xcode. Kaleidoscope is vital to my workflow when running diffs on my Git commits. It’s too bad this is seemingly abandonware. It’s a great app that I plan to keep using until it no longer launches.
- Patterns: I don't think I will ever fully grasp Regular Expression syntax. Patterns makes it easier for me to fumble around trying to build and test a regex compared to doing sample finds in Sublime Text.
- QuickRadar - The RadarWeb UI still sucks. QuickRadar makes me more likely to file bugs because it is in my Dock, it can cross-post to OpenRadar, and it has never crashed or lost a bug report while I was trying to submit it.
- Realm Browser - Core Data is trash. I’d use Realm for every app if I could. Since Realm uses a custom format for its database you need an app to inspect it. For SQLite you use Base. For Realm, you use this.
- Paw - I keep a Paw document for each API that I interact with so that I can quickly test out API calls to see what the JSON returned is.
- Sketch - If you work with a designer they are most likely using Sketch. Keeping a copy nearby so you can inspect files is handy. I also use it for my super rudimentary design on this site.
- Slender - If you're using Xcode I bet you have a few assets in your Xcode project that are no longer in use. Those kilobytes are wasting your customers' bandwidth and yours. Slender analyzes your Xcode project and finds those assets that are no longer in use so you can safely delete them.
- Slack - If you work for a startup, you are contractually required to use Slack at this point.
- VS Code - If you take all the disdain I have for Xcode and inverted it, you’d have my affection for Visual Studio Code. A powerful programmer IDE that gets meaningful monthly updates and has a vibrant, useful plugin community? I’m in love.
- xScope - I use xScope to detect colors on various UI elements, check alignment of controls and to measure the distance between objects. If you (or your designers) are meticulous about your UI, it's an essential utility.
- Acorn - Acorn is my favorite image editor for the Mac. It's fast, intuitive and looks pretty neat too.
- Backblaze - While I primarily rely on Time Machine for my backups, I also subscribe to Backblaze to offload the contents of my hard drive to the Internet for when I am burglarized for the third time this decade.
- iStat Menus - Since Swift enjoy eating CPUs for breakfast, I like to have a quick way to see how taxed my system is during compilation. iStat sits in my menu bar and gives me all the essential info I need.
- OmniOutliner Pro - When I am doing more complex writing projects than a blog post, I outline the entire thing in OmniOutliner. The ability to have drop-down fields is one of my secret weapons. Love that.
- Pastebot - I never thought I would be one of those clipboard manager people, but Pastebot is so simple that I converted. The ability to sync my clipboard over iCloud is honestly what won me over. It’s like Handoff’s copy/paste support, but reliable.
- PDF Expert - Preview is a fine PDF viewer, but I’ve come to adore PDF Expert because of its editing capabilities and super easy signing of documents.
- Rocket - If you’ve adapted to using Slack for throwing emojis out, Slack brings that functionality to your Mac. Now I can easily throw out a 💯without a few keystrokes.
- Soulver: Soulver is the best calculator app on the planet. There is no debate.
- The Unarchiver - A file extraction utility is somewhat of an unsung hero, but when you need it, it's good to have a utility that is robust and can fit almost any bill. The Unarchiver does that and does it well.
- TunnelBear - Since the United States Congress seems keen to allow ISPs to sell all my data without my consent, I tend to run a VPN as much as possible these days. TunnelBear is my preferred one for the last few years. It doesn’t hurt that their branding is adorable.
- Twitter for Mac - You probably use Tweetbot, but I actually prefer the official Twitter client for desktop tweeting. Sorry to all those offended.
- Ulysses - I wrote this entire post in Ulysses. In fact, I do most of my writing in Ulysses these days. It’s both a fantastic Mac and iOS app.
This is one of those "it's obvious in hindsight" problems I ran into recently.
At the day job, we have been migrating all of our logging code from Aspen to Apple's new Unified Logging System. This has been a win for the most part: we got to terminate a third-party dependency, while also getting some advanced features such as log filtering based on a category or subsystem.
The problem I ran into last week was trying to debug a background session issue on my iOS device. We use the different logging levels provided by
os_log to help keep users logs a bit less chatty than just spitting out
NSLog statements everywhere. By default, the new Console app in macOS Sierra only shows logs that match the
error level (or have no level at all). I needed to see our debug and info log information.
If you watch the WWDC video on the new logging system they show you a few Terminal commands you can run to adjust your logging level on the Mac. It doesn't really show you how to adjust that for an iOS device plugged into your Mac, however.
Long story short, there's no Terminal command. There's two options in the "Action" menu on the Console. Just select "Include Debug Messages" or "Include Info Messages" and you are good to go.
I sure felt dumb once I figured that out. You win this round, Apple.