I’ve been an iOS Developer for just over 10 years now – 30 years of professional experience overall – and I still suck at Interface Builder and Auto Layout. 🤪
I’ve been able to work a little bit on my beloved side project, Stream. For those not following along, or those that have forgotten, Stream is my Twitter-like News Reader.
Life changed pretty dramatically for is over the past nine months or so. Our daughter, grand daughter, and son-in-law moved to the east coast. Kim and I had a two year plan in place to move back east so we could be near them, living in California doesn’t make for easy day trips to visit when we want. That is another story all together. Suffice it to say serendipity struck and we moved the timeline up, way up.
We arrived in Virginia November, 1 and moved into our new home. Yes, it was extremely fast. All the work surrounding the move meant I really needed to focus on all things related to the move and let the side project sit. Now that we’re settled in our home and I’m settled in at work I finally got Stream out of moth balls and worked on it a bit.
### Crashing Sucks
I had sent out a few TestFlight builds to folks but I knew where the ugly parts of the code were. I pushed it out way too soon, I realized that after a couple builds. I should have finished all features before user testing became a thing. Live and learn.
I found two things that bugged me more than anything else; the app would crash on occasion and syncing feeds was way too slow.
A couple weekends back I was able to plant myself on the couch and work through the performance issue and the crasher. I can thank [Brent Simmons](https://inessential.com/) for the most significant performance wins. His [blog posts](https://inessential.com/2013/03/18/brians_stupid_feed_tricks), tweets, and Slack messages about feed reading and general [Cocoa Framework oddities](https://inessential.com/2019/12/30/kvo_my_enemy) have proven invaluable. I only hope I can pay his kindness forward at some point. Thanks, Brent.
Ok, on with the wins. The first two tips I picked up.
### Handle 304 HTTP responses
This one was an instant performance boost if servers hosting feeds actually return it. If you’re making 100 network requests to update your 100 feeds it can be kind of slow to parse all the resulting data. But what it you don’t need to parse the results? Right! The data you don’t have to parse makes your code faster. Imagine that!
### Create a hash of the response data
So, what if you ask for feed data and it hasn’t changed but the server doesn’t return a 304 indicating it hasn’t changed? Well, you create a hash of the response data and keep it for later. Next time you grab the feed, hash it and compare it to the hash you created last time.
### One more thing
After reading Brent’s piece about KVO crashes I decided to stop using NSOperation and NSOperationQueue. I was only using it so I could create dependencies that would allow me to have a final operation that updated the UI’s data source. Now I don’t do that. I just rely on [URLSession](https://developer.apple.com/documentation/foundation/urlsession) and [URLRequest](https://developer.apple.com/documentation/foundation/urlrequest) to do the job.
### Not done
I feel a lot better about the performance but I know there will be more changes down the road. Moving forward I need to focus my effort on finishing the UI and adding some niceties like a share extension to add a feed and things like dark mode support. There are other things I’d like to do as well. Least of which is building a Stream Mac App. 😀
I’ve adjusted my personal expectations to ship before WWDC this year. Let’s see if I can make it.
Becky Hansmeyer: “My code sucks. It just does. I’m inexperienced, I’ve had no mentors or code reviews (by choice—I’ve had offers from many great people!), and there are fundamental concepts of programming that I only have a tenuous grasp of, at best. Despite my best efforts, I’ve utterly failed at using the MVC model. My views are all up in my model’s business, I probably have delegates where I don’t need them, or, on the flip side, other weird hacky ways of communicating between view controllers (like via viewWillDisappear and unwind segues, and all sorts of odd places) where I should have just used a delegate.”
You know what, Becky. My code sucks too. I’ve been doing this professionally for 30-years and my code is still crap. I work really hard at honing my craft. Continually learning is the key to longevity in this business so just keep plugin away.
Becky here’s something to keep in mind. You’ve shipped a successful product. Nobody cares what your code looks like. You shipped! In the end that’s all that matters.
Remember this: the only bad code is code that never ships.
This set of questions is from November 13, 2015 regarding Xcode for iPad. They still hold true today.
- Who is it for?
- What would the experience be like?
- How would debugging work?
- Would you have a mouse?
- How would you debug for other OS versions?
- Would it be iOS only?
- What about Mac?
- Would it be Swift only?
- Would it introduce a new framework?
- Split screen debugging?
- What about iPhone?
- iPad Pro only?
I was just reading a Slack channel I’m a part of and someone was asking if it’s difficult to add Swift to an Objective-C project. It’s not. Basically you should add a bridging header to your project so you can call your Objective-C code from Swift then do a full nullability audit on any code you’d like to call from Swift. That’s it in a nutshell as far as I can remember.
Another thing to keep in mind as you start writing Swift. Just start writing code. It doesn’t matter if it’s “swifty” or not. I’m an old C/C++ developer and people probably think my Objective-C and Swift look like an old C/C++ developer wrote it. Sure, there are nice things in the language you’ll learn to take advantage of but, to get started, just write code.
I don’t like to install beta versions of iOS on my daily driver device so I tend to use old devices I have left around from years past. This year, however, I didn’t have a device capable of running iOS 12, so I bought a used one on Letgo.
For $60US I was able to purchase an iPhone 5s with a cracked screen that works just fine. I decided to pickup a new screen from iFixit for another $40US. All in, $100US and I have a great new test device. It actually runs iOS 12 really well.
So, if you’re short on cash, try a used device for testing.
Why doesn’t Apple improve on the iPod Touch every couple years? Why not take older chip sets — maybe a model from last years iPhone — and leave the form factor alone? Just keep stuffing updated tech into the existing design.
There are folks that can’t afford to buy their kids an iPhone but the iPod Touch may fit nicely into their budget.
As a developer this is also a nice machine for testing. The only issue I see is it hasn’t been revved in a long time. It’s still using an A8 processor but it is still slightly ahead of the iPhone 5s which uses an A7. that’s important because the iPhone 5s is the lowest end iPhone that supports iOS 12. That means we could get another couple years use out of the current generation iPod Touch.
The iPod Touch with 128GB of storage sells for $299US.
Fingers crossed Apple updates it soon.
- a sweet, yellowish paste of ground almonds, sugar, and egg whites, often colored and used to make small cakes or confections or as an icing for larger cakes.
- a new Apple Framework for building Mac and iOS Apps from the same source code.
A unified Apple Framework makes sense. By this time AppKit is fairly old, it began life at NeXT and moved forward as Apple’s new framework on macOS. When Apple created iOS it made sense to reconsider the user interface and user experience for a touch based interface. Having support for mouse clicks and menus didn’t make a lot of sense for something so small controlled with your finger. Enter UIKit.
To say iOS became a shooting star, Apple’s crowning achievement, would be an understatement. It’s wildly popular amongst users and developers alike. So much so Apple has kind of pushed macOS into the background and allowed its younger brother to take center state. It’s not that macOS isn’t popular — because it is — it’s just that iOS is much, much, bigger than anyone could’ve estimated. As a result Apple spends most of its time working on iOS, or at least it seems that way.
In the episode Marzipan: Apple’s Next Big Software Thing! of Rene Ritchie’s VECTOR he discusses Marzipan with a lot of well known developers and writers. None of the folks go as far to think Apple could be making a monumental leap forward with Marzipan. What if Apple goes all in on a brand new framework completely written in Swift? I know it’s not likely to happen, but what if it does?
Obviously that would be hugely upsetting for the Mac and iOS ecosystem. But on the flip side it would give developers a clean slate to work with. Something designed to work for touch and mouse and keyboard input. It would give Apple the chance to shake off years cruft and reimagine applications and frameworks without the constraints imposed by Cocoa or Cocoa Touch.
Am I crazy? Yes, a little. I know current developers — especially Mac developers — would lose their minds. It would be the second time Apple changed direction on them in a potentially radical way. This wouldn’t be quite so egregious. The move from Mac OS 9 to Mac OSX was monumental. A brand new OS and a brand new way to code, not easy to adjust to after years of working with an OS and API. Carbon eased folks into it, but the transition was still extremely difficult for some development shops, like Adobe.
Of course they don’t have to go all in. I doubt they’d be that extreme. There are simple things they could do to unify Cocoa and Cocoa Touch. An extremely simple example I can think of is unifying NSColor and UIColor. Over time we’ve seen some text attributes move to their NS* counterparts, why not start with the simple things and work down the stack?
I also don’t consider going from iOS to macOS cross platform. I know they’re slightly different but they are in the same family. If you’re doing iOS development macOS should feel somewhat familiar to you. Sure the controls are different on the platforms and there’s the matter of touch vs. mouse driven, but I believe calling Cocoa based applications cross platform between Mac and iOS is a bit of a stretch. If you’re taking one set of code from iOS to Windows that is what I’d consider cross platform.
Post WWDC 2018 Thoughts
I penned everything above quite a while back, March 11, 2018 to be exact.
While on stage at WWDC Apple announced UIKit for Mac. Four UIKit for Mac applications will ship with macOS Mojave this fall; News, Stocks, Home, and Voice Memos. This is great news for anyone interested in bringing their own iOS Applications to macOS. It means Apple is dogfooding UIKit for Mac while it’s in active development. From all reports it’s really rough around the edges but we can all hope some of those edges are smoothed out before Mojave makes its debut but it’s ok if the applications and framework are a bit rough at first. Why? Apple said on stage UIKit for Mac wouldn’t be generally available until 2019 and that it was a multiyear project. This tells me we should expect a gradual move of UIKit downward into AppKit until UIKit either becomes a part of AppKit architecturally or the Mac specific bits of AppKit become a part of the “new” UIKit for Mac.
In many ways it feels like UIKit for Mac is the right direction. It’s been running on macOS for 10 years. If you’re a developer you’ve used the Simulator everyday to run your iOS Apps on your development machine.
Any developer will tell you shipping software is difficult, especially if you’re driven by deadlines and not feature sets. Given Apple have already announced four applications shipping with Mojave they’re going to have to make really tough decisions to make sure these select applications are ready by fall. It seems reasonable to expect these first UIKit on Mac applications will have a decidedly wonky feel, not quite native. There will be telltale signs, little things, that drive native app seeking people crazy. Things like seeing a UIAlertController instead of an NSAlert when an app needs to inform you of something or ask a question. It makes the application feel unnatural.
At the beginning I’d expect UIKit for Mac to either reach down into AppKit to do the work or reach under the hood and use the same lower levels AppKit uses. Conceptually this is how UIKit living on top of AppKit looks. It’s a way to bootstrap your new Framework into being. Leveraging what AppKit already does seems a reasonable way to just make it work.
As time goes by I would expect more of AppKit to move upward into UIKit. UIKit becomes the new preferred framework for building applications on Mac. Maybe it gets a new name? Maybe not? As that transformation begins taking shape we’ll see UIKit itself transform to feel native on each platform. Mac apps will feel like Mac apps and iOS Apps will feel like iOS Apps. It’s not rocket science. Applications for each OS should feel like they belong. No compromises. Hell, we can write Electron Apps if we want compromise.
As Craig Federighi pointed out on stage at WWDC this is a multiyear effort. Expect things to be ugly at times from the user perspective and the developer perspective. In fact I expect it to be the development effort going forward for iOS and Mac UI Frameworks. Until — of course — the next shiny framework comes along.
This is from a July 2017 tweet. You see, I’m working on a blogging/editing tool for Mac, iOS, and Windows and it really caught my eye.
iPad users: what text editing app should I try? I’ve tried and disliked Editorial and Ulysses. I can hold my nose and use IA Writer.
— John Gruber (@gruber) July 12, 2017
Today John tweeted that he was looking for a good iOS text editor. He was looking for recommendations because he wasn’t happy with iA Writer, Ulysses, or one other one I can’t remember.
It sounds like he wants Vesper back. That’s very interesting to me. He says they “don’t feel right.” That’s also interesting.
I checked out the apps he mentioned. They’re all beautifully designed. iA Writer looks super interesting as does Ulysses. It’s very difficult to put a finger on what appeals to John. I suppose Vesper is the answer?
Ultimately it looks like John is after TextEdit on iOS. Plain Jane â€” to the point â€” text editing. Makes sense.
Has anyone created TextEdit for iOS yet?
Bloomberg: “Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether itâ€™s running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter. “
This is something I’d welcome. I’d love to see a 12-inch MacBook sized laptop running iOS that allowed touch input and mouse input. That would be amazing.
I know that’s not what the article says, but it’s something I’ve been thinking about for a very long time. I think Microsoft Surface Pro is a wonderful computer and I don’t see why Apple couldn’t make something like it. Of course there will be much gnashing of teeth, but it seems an obvious compromise for a hybrid experience.
Guess I’d better hurry up and finish up my Mac App so I can get started on the iOS version?