Do you remember Parse? The MBaaS platform that Facebook acquired in 2013 and closed down in 2017?

Let’s recap some history, as it’s been a while! I first linked to it in Issue 2 of this newsletter! 😱 The concept was brand new and very tempting. It promised no need for custom back-end servers—Just integrate the client library, define model objects, and save data to the cloud. Easy! It was Firebase or AWS Amplify, but ten years ago. Parse lasted longer than their major competitor, Stackmob, who was acquired and then shuttered just a few months later. But eventually, in 2017, Facebook turned off the hosted Parse servers.

They did open-source the platform as they closed it down, partially due to the huge number (600,000, according to this article) of apps they'd disrupt without a migration path. I was vaguely aware that the open-source project was still around but I hadn’t paid much attention until I spotted this package pop up in the Swift Package Index RSS feeds this week.

The README looked impressive and seemed to be primarily created by one person, Corey E Baker. I was curious, so I reached out to him, and he explained that his interest came out of wanting to sync some CareKit data through to Parse. The Parse server has received consistent maintenance, but Corey explained that while still functional, the Objective-C client had fallen behind with implementing some newer server features. He jumped in and started working on the Parse Swift library, and just look at that graph! 🥳

Why am I writing about this? Well, it has always been risky to base an app on another company’s back-end server. Yes, it can save a lot of time, but you’re always at the mercy of another company’s business decision, and their priorities almost certainly don’t match yours. Maybe the platform you pick will shut down, fundamentally change its pricing, or make another decision that doesn’t work for you. Your options are limited as these frameworks live at the heart of your app. The Parse platform is now free of many of those problems. As it is open-source, it’s almost impossible to shut down, and being self-hosted, you’re in control of pricing. Even better, the server has been around long enough now that it should be pretty stable and feature-rich. Then, with the tremendous amount of work that has recently gone into the Swift client, it’s looking like a promising project for iOS and macOS apps again.

It’s also so lovely to see a successful project rise out of the ashes of yet another “acquire and shut down” situation. The project is well funded enough to run a Paid Contributors Program, and that’s a terrific thing to see! I was so happy to discover this little corner of the iOS world thriving when I thought it had faded away.

Maybe check it out next time you’re reaching for Firebase or Amplify. 💡

Dave Verwer

Transitioning from Intel to Apple Silicon

What does Apple's architecture shift mean for your app development workflow? When should you move to M1 Macs? MacStadium's free eBook will help guide the way in transitioning your Mac or iOS app build pipeline from Intel to Apple silicon.

macstadium.com

EU plans legislation forcing equal hardware/software access to all

This is a fascinating provisional agreement and, if enforceable, could mean enormous changes to tech everywhere. It feels completely unreasonable to say that companies can’t use the hardware inside their devices until there is a full public API. Maybe there’s a version that sets a time limit on exclusivity or something like that? That still gives an advantage to the company making the product, but I don’t see anything else as practical or enforceable.

I will keep an optimistic view on this for now and hope that this legislation, if passed, is implemented sensibly. 😬 Please wish me luck with my optimistic view! 😂

macrumors.com

Celebrating learning experiences from the Swift Mentorship Program

I'm so happy to see this programme preparing for its second year! Devanshi Modha has a great recap of some highlights from last year, including write-ups by Anh Pham, David Reyes, and Amritpan Kaur. I'd also like to thank Sarah Lichter personally for her contributions to the Swift Package Index as part of this programme. I can't wait to get involved again this year.

swift.org

Account deletion requirement starts June 30

Will it stick this time? I think it has to. So, if your app lets people create an account and does not yet let them delete it, I'd get on it as a priority! ⏱

apple.com

Introducing the Accessibility Workspace

You may have seen this feature demonstrated in the accessibility event that I linked to last week, but if not, then this blog post by Chris Kolbu is worth a look. Evaluating the accessibility of your apps is hard, and it's especially tough to see when you inadvertently break something, so any feature that can help you keep track of accessibility issues is valuable.

For full disclosure, Reveal has previously been a sponsor of this newsletter.

revealapp.com

Faster Xcode builds when switching branches

I hadn't come across git worktree before reading this article from Max Godfrey, but it's an interesting command, and Max makes an excellent case for using it with Xcode. I had a quick play with it, and while it worked well, it didn't quite work how I expected it to. The best way to think about it (from my very short experience with it!) is that it almost "detatches" a branch into a separate working directory when you add a worktree, and then puts the branch back when you remove the worktree. It's a handy feature!

medium.com

Swift Snippets

I don't link to Swift Evolution proposals often, but I had to make an exception for this one. Validated snippets of sample code that you can keep current and working via testing them in CI are so valuable, especially if you're writing a package or library for other people to use. I love that the Swift team feels strongly enough about this to prioritise it, and I hope it sails through the review process.

github.com

Mastering TimelineView in SwiftUI

The best thing about SwiftUI is that your data and views can never be out of date. Your views always represent the current state of their data source. Wait... what's that you're saying, Majid Jabrayilov? TimelineView doesn't work like that? Well then, I'd better read this article! Thanks Majid. 👍

swiftwithmajid.com

Understanding identity via transitions in SwiftUI

This post from Raheel Ahmad is excellent. Understanding identity and how SwiftUI thinks about diffing views is key to creating successful animations or transitions, but by choice rather than SwiftUI guessing what to do!

sakunlabs.com

Senior iOS Developer @ Flightradar24 – Join the team at Flightradar24, working on the world's most popular flight tracking service. This is your chance to be part of our small but mighty mobile team, work on every part of our iOS app and have a big impact on over 3 million daily users. – Remote (within European timezones)

Staff iOS Engineer @ brightwheel – At brightwheel, our vision is high quality early education for every child. Early education is a $100 billion market in the United States. There are more preschools than restaurants in the US, so the opportunity for impact is immense! – Remote (within US timezones) or on-site (United States in CO or TX)

iOS Developer @ Konrad – Konrad is an amazing community of the brightest minds in tech. We build bleeding edge mobile applications for some of the largest, most exciting companies in the world. We have a team of 250+ developers that work with the latest technologies. – Remote (within US timezones) with some on-site work (Canada)

iOS Developer @ MFB Technologies, Inc. – Be one of two primary developers responsible for our #legaltech iOS application. The app (written entirely in SwiftUI using functional programming) is currently in beta at a major law firm. You will be given flexibility, resources, and time to add features and improve its architecture. – Remote (within US timezones)

iOS Engineer @ Karbon – Karbon has spent the past 12 years building amazing apps for the best clients in the world. We’re a fully remote yet closely-knit team of iOS and Android engineers with an obsessive attention to detail. We value quality over quantity and focus on only a few key projects per year. – Remote (within US timezones)

Mobile Full Stack Engineer @ Expensify – Join our passionate team of top-notch engineers to solve a real-world problem, and help people spend less time managing expenses and more time pursuing their real goals. – Remote (Anywhere) with some on-site work (Australia, United Kingdom, or United States in CA, MI, NY, or OR)

Senior iOS Engineer @ Doximity – Doximity, the medical network used by over 80% of US clinicians, is hiring passionate iOS engineers (fully remote!). Come be part of an amazing product team + work on an app that is constantly evolving. Use your skills (Swift, MVVM, FRP) to be an integral part of our newly launched telemed feature. – Remote (within US timezones)

Senior iOS Engineer @ onX – Are you a Software Engineer that loves the outdoors? onX is hiring iOS Engineers. If you’re passionate about building great software, love playing outside, and believe in protecting access to public lands - then join onX, where we empower millions of outdoor enthusiasts to explore the unknown! – Remote (within US timezones) or on-site (United States in MT)

Want to set yourself a new challenge with a new job? Check out over 40 other jobs on the main iOS Dev Jobs site. Download the apps and get a notification whenever a new job matches your filter. Want only to work remotely? There’s a filter for that!

These are the WWDC leaks that I'm here for. 🤘