Something struck me as I read Daniel Saidi’s blog post on hiding the iOS home indicator with SwiftUI. It relates to the hackability of SwiftUI versus UIKit/AppKit.

Yes, SwiftUI is getting significantly more capable every year by adding view modifiers like the one in Daniel’s article. However, I’m not sure the plan is for developers to have quite the same level of control as is possible with UIKit/AppKit. Yes, it’s still possible to perform tricks, but Apple has repeatedly said that the underlying implementation will not always use UIKit/AppKit as SwiftUI matures, and I’m sure they’d never suggest an approach like that.

But there’s some subtlety to how Apple is controlling this API design. SwiftUI has loads of flexibility in certain areas. Take List or Grid, for example. Cell design is entirely down to you. Go wild with it and create your disco UI there!🕺🪩💃🏻. It only gets more tightly controlled with the higher-level areas of design, like navigation.

There are advantages to having navigation be more locked down, though, like cross-platform development (where the platforms are all Apple platforms, of course). The new NavigationStack layout is significantly different between a macOS app and one on iOS or watchOS, but all you need to think about is the underlying hierarchy. Even if we rule out all platforms other than iPad and iPhone, I don’t think anyone would argue that it’s easier to set up standard navigation for iOS in UIKit vs SwiftUI.

I also read Nick Babich’s piece on ordinary design this week, and the points he makes also fit this topic well. So many apps on my phone have tried to re-think or implement their custom navigation, and virtually all of them would be better off with something more standard. Nick points out that the “ordinary design” suits most people, and while you can certainly aim to make a statement with design, that’s not the best choice for most apps.

Make apps like Toyota makes Corollas. Save the disco UI for where your app is unique, and that’s not the navigation UI.

Dave Verwer  





iOS SDK Developer @ Stream – You will write and maintain our open-source SDKs that are used by hundreds of our customers and consumed by hundreds of millions of their users. – Remote (within US timezones)

Senior iOS Engineer (Swift) @ GoodNotes – GoodNotes is a top-rated paid-for productivity app, available to use on iPad, iPhone and Mac devices with over 10m MAU. You will own your projects and work alongside a high-calibre cross-functional team to continue delivering a product our users love! – Remote (within European or Asia-Pacific timezones) or on-site (Hong Kong or United Kingdom)

Senior iOS Engineer @ Sendwave – We currently have a 4.6-star rating on Trustpilot — people put their faith in us to deliver their money quickly, securely, and affordably. And we’re pretty darn proud of that. – Remote (within US or European timezones)

MacOS/iOS Developer @ DeepL – DeepL is hiring! Want to join the team behind the internet's most powerful translation engine? We are seeking an experienced MacOS/iOs developer to join our Native Apps team, on a fully remote basis. – Remote (within European timezones)

Senior iOS Software Engineer @ Cambridge Mobile Telematics – Cambridge Mobile Telematics (CMT) is on a mission to make the world’s roads and drivers safer. We measure driving quality, incentivize safer driving, assist users in crashes in real-time, and improve safety for millions of drivers every day around the world. – Remote (within US timezones) or on-site (United States in MA)


Don't forget that there are many more available jobs over at iOS Dev Jobs. What's the harm in having a quick browse?


And finally...

It’s so strange. Our analytics say that 78% of new users make it to the signup screen and then go no further… 😂