Sponsored Link
Building Mobile Apps at Scale: 39 Engineering Challenges
140+ pages of insights on building for mobile at scale, sourced from teams at Google, Uber, Amazon, and more. Download a free copy!
bitrise.io
News
TestFlight for macOS Beta
I discovered TestFlight for Mac had shipped yesterday when I was uploading a new build to App Store Connect, and I noticed one less tab across the top. I even thought, “Oh, maybe they shipped it just now, and I’m first to see it! Of course, I checked Twitter and saw that everyone had been talking about it for many hours. 🤷♂️
The good news is. TestFlight is finally here for macOS, as long as you’re enrolled in the developer beta programme and are running Monterey. 😬
apple.com
There are no App Store changes in this press release
I don't know what happened yesterday. 🤯 Apple published this press release, and every news outlet I saw ran with a story of "big changes" to App Store rules. What's strange is that nothing has changed, and the press release says explicitly. The Verge's piece on it still has "changes a key App Store rule for developers" in the headline. It's bizarre.
The bullet in the press release causing all this confusion is:
To give developers even more flexibility to reach their customers, Apple is also clarifying that developers can use communications, such as email, to share information about payment methods outside of their iOS app. As always, developers will not pay Apple a commission on any purchases taking place outside of their app or the App Store. Users must consent to the communication and have the right to opt-out.
You have always been allowed to offer an in-app mailing list opt-in, either as a stand-alone mailing list or as part of account creation. Once you have an email address and permission to email it, Apple is no longer involved in any part of that relationship. You may email that customer whatever you like.
What makes this even more bizarre is that the text even says, "Apple clarifies". The press release is crystal clear, and as far as I am aware, it was not edited after publication.
This event is depressing in two ways. First, the reaction to the press release and second, a "successful" lawsuit resulted in zero changes.
Note: I guess the rather depressing answer to this puzzle is that headlines like this get clicks, and clicks pay the bills.
apple.com
Code
Custom Dump
Swift's dump function is useful almost every day, but could it be better? Enter customDump and friends. A new library from Stephen Celis and Brandon Williams. Better formatted output, diffing of results, and lots more.
I wonder if there's any appetite for moving some of this towards being part of Swift? It feels like it'd be a nice improvement to me.
pointfree.co
Why Conditional View Modifiers are a Bad Idea
If you've wished for SwiftUI conditional view modifiers, and if you've done any SwiftUI you will have, then you should read this article from Chris Eidhof as the common technique to make it possible is flawed in subtle ways.
The need for some kind of conditional modifiers is real though. I hope it's something Apple is working on.
objc.io
Every SwiftUI Environment Value explained
What a handy post from Federico Zanetello. I won't go into detail here because the post title is clear and descriptive, and it contains exactly what you'd expect. 👍
fivestars.blog
SwiftUI Tools with SwiftPM
Can you write a SwiftUI app without an Xcode project? Helge Heß has a go.
alwaysrightinstitute.com
Design
The Beauty of Bézier Curves
This video from Freya Holmér is wonderful and explains everything you could ever need to know about Bézier curves. It's also part of the reason today's newsletter is so late! 😅
You won't need to know everything in here to do an ease-in or ease-out animation or draw a curve, but if you've any interest in the subject or the maths behind it, you'll love this.
youtube.com
Jobs
Senior iOS Developer @ Grailed – Grailed is one of the largest peer-to-peer clothing marketplaces. We use RxSwift, functional programming, and agile practices and we also get to interface directly with users to build and develop features for the app. We are committed to clean code, supporting work-life balance, and enjoying life! – Remote (within US timezones)
Senior iOS Engineer @ Circle – We're a cross-platform community product built for web and mobile, and we're looking for a Senior iOS Engineer to help take our iOS app to the next level. Our iOS team is small and lean, so you'll get a ton of responsibility in building critical features for our iOS app. – Remote (within US or European timezones)
Senior iOS Engineer @ Marshmallow – Marshmallow is building a world where insurance benefits everyone. We’re looking for iOS Engineers to join our mobile team at Marshmallow to help us rebuild insurance – for good! You'll have the opportunity to help shape the roadmap, impacting both what we build and how we build it 🚀 – Remote (within European timezones) with some on-site work (United Kingdom)
Lead iOS Engineer @ Hillrom – Hillrom’s Voalte Mobile software solutions focus on being the best communication and collaboration tools for healthcare care teams. The product offering has multiple mobile applications, web applications, and server applications. – Remote (within US timezones)
iOS Engineer @ Mercury Intermedia – We build award-winning apps for a variety of mobile platforms and global brands including sports, entertainment, and retail. We fly under the radar, but our work sure doesn't. You probably have one or two of our apps on your phone right now. – Remote (within US timezones)
Senior Mac / iOS engineer @ Beam – A unique chance to work in a talented multidisciplinary team (ML, NLP, web, and crypto) to change the way people experience the Internet. – Remote (Anywhere) with some on-site work (France)
Senior iOS Developer (m/f/d) @ SIXT – Join SIXT in shaping the future of mobility! You'll be joining our growing team of 35+ iOS engineers spread across multiple continents. With us, you have the chance to work on exciting projects in our highly modularized native Swift app, explore new innovative technologies or build your own ideas. – On-site (Germany) with some remote work (within European timezones)
iOS Engineer @ Lickability – We’re a software studio making apps for clients like Houseparty, Clubhouse, & The Atlantic. We’ve also created a few of our own: Scorecard & Buildwatch. We’re hiring a full-time remote iOS engineer in the US. And, we have a four-day workweek, so you can take Fridays to rest, learn, & live your life. – Remote (within US timezones)
Sr. iOS Engineer @ MyPlate from Leaf Group – MyPlate is an award-winning app, transforming tens of thousands of lives on a daily basis. Our mission is to make users happier and healthier by simplifying their nutrition data. We are looking for a Sr. iOS Engineer to help us grow MyPlate as a business. – Remote (within US timezones)
iOS Developer @ Bontouch – Bontouch is an award-winning product innovation agency. We have a simple but ambitious idea: to make the world’s greatest apps for the best brands on the planet. Join us and work with fun, passionate coworkers with different backgrounds creating world-class digital experiences for million of users. – On-site (Sweden) with some remote work (within European timezones)
iOS Engineer @ Govenda – Build NATIVE for a women founded company. Work with a variety of exciting technologies such as video conferencing and eSignatures. Collaborate with an awesome group of engineers across a variety of platforms. Ship code for both iOS And Mac OS! – Remote (within US timezones)
iOS Software Engineer @ Sky Betting and Gaming. – Do you love iOS development? Do you build large scale apps? Join us in the Bet Engineering team, where you’ll be part of an agile, native app squad responsible for the delivery and upkeep of our flagship Sky Bet product. Our ambitions are to deliver an incredible native betting & gaming experience across all our SB&G products! – Remote (within European timezones) with some on-site work (United Kingdom)
Senior iOS Engineer @ Sky Betting and Gaming – We are looking for an experienced iOS Engineer to join the first iOS squad in our Customer Tribe at Sky Betting & Gaming! Working collaboratively with the squad you’ll be building an account UI and SDK for our full range of products using Swift, Combine and Modern UIkit in order to create the best possible experience for our iOS customers. – Remote (within European timezones) with some on-site work (United Kingdom)
Principal Mobile Engineer @ Sky Betting and Gaming – The Principal Mobile Engineer role is the ultimate role for an engineer who has been there, done it and got the t-shirts, stickers and battle scars to prove it! Join the Bet Tribe to continue our journey to a fully native iOS app, influence the tribe to think native-first and drive the best possible customer experience! – Remote (within European timezones) with some on-site work (United Kingdom)
As someone who has just released a SwiftUI app across three platforms, this tweet from Steve Troughton-Smith perfectly sums up today’s reality vs the promise of this technology.
It’s so much better than when it debuted in 2019, and yet we’re still probably three to five years away from the point where “Should I use UIKit/AppKit or SwiftUI?” won’t be the first question people ask when starting a project.
The scope of the Dev Jobs app is tiny. It’s a split view with a list on the left-hand side and a web view on the right-hand side. It’s so limited in scope that I had genuine doubts about whether it’d get through App Review on the “Apps must have significant functionality” requirement. I’m happy to say it got through without even a discussion in that area, and I do believe it stands up as being a worthwhile app, but the fact that I considered whether it’d get hit for that should prove the scope of what we made.
Yet even for something so simple, you’d probably be a little bit horrified if you looked at the code. It’s littered with so many
#if os(macOS)and#availabilitychecks. It also needs Introspect to get at underlying UIKit components in a few places.But that’s not the worst of it. As Steve said in his tweet, the output is also inconsistent. Buttons have correct sizes and padding in some places and not in others. Positioning varies by platform and container hierarchy, and that’s often where the #if magic starts. There are also real problems when moving from iOS 14/Big Sur to 15/Monterey too. Some things get better, and some get worse, resulting in more conditional logic. It can be quite a mess. We also let many of the issues slide, only fixing the most egregious ones. That’s partly due to the limited time we had available and partly because I believe the issues will get resolved, and any hacks to make it better are likely to make things worse later. The code would be much worse if we worked around all the issues.
But there’s another side to this. Two of us built the app across three platforms from “New Project” to “Submit for Review” in ten days. I think that’s quite remarkable, and there’s zero chance that would have happened if it had been a UIKit/AppKit app. We could have shipped a UIKit app in ten days or an AppKit app in ten days, but not both. SwiftUI made that feasible.
I believe in the promise of SwiftUI. If/when it’s at the point where it can truly replace the existing UI frameworks, we will be in a better place. There won’t be fourteen different toolbar designs in fourteen iOS apps. We’ll only have toolbars that follow platform conventions. I believe we’ll end the journey in a better place, but it’s worth remembering that even though SwiftUI is almost all everyone talks and writes about, it’s still very much bleeding edge.
Dave Verwer