Store & Sync Realtime Data with Firebase
Using Firebase's powerful iOS SDK, you can easily build realtime apps without worrying about networking, scaling, or writing complicated server code. See how it works and start developing instantly.
New: Deep link users to the right place inside your app, even after app install
Firebase Dynamic Links are smart URLs that allow you to send existing and potential users to any location within your iOS and Android apps, even if they don’t have it currently installed. Once installed, users will be automatically sent to the original link they clicked on and see the content they we’re looking for. Dynamic Links are free forever for any scale, and are already in use by many of the apps you use daily.
Since Parse died (or did it?) the market for cloud hosted data store services has still been evolving, but at a much slower pace than before. There's Realm and of course there are the big players like Azure and Firebase. So what is Cloud Firestore from Google then? Well... it's kinda like the Firebase Realtime Database, but different... Here's a detailed comparison between the two. Interesting!
Is Apple Banning Free Analytics SDKs?
There are some great points raised in this post from Allen Pike, but this sentence from his conclusion should stop you in your tracks if you use Firebase:
all iOS apps should be prepared to migrate off of the Google Analytics, Firebase, Facebook, and Flurry SDKs, potentially on very short notice
I intentionally stopped linking to anything related to Firebase (and similar services) part-way through 2018 as, in my opinion, putting a third-party library at the core of your app was too big a risk. Alan's article isn't specifically about Firebase, but the dependencies you embed in your app, and the privacy policies that come with it, should be a part of your decision process. It's one thing to need to switch out your analytics provider on short notice, but I can't imagine trying to replace Firebase in a non-trivial app.
For full disclosure, Firebase sponsored this newsletter back in 2014.
Catching smiles with Google’s ML Kit on iOS
I mentioned last week that MLKit was usable on iOS through Firebase and sure enough Martin Mitrevski has provided us with this example of smile detection with MLKit. 🤖
This isn't surprising, I've been expecting an announcement ever since the acquisition last year. The bad news is that Firebase is now a required dependency if you want to continue using Crashlytics, and that some other features of Fabric are going away completely. It's not that Firebase is bad, far from it! You'll even get more features when you make the switch, but it is a big dependency if you were previously only using Crashlytics.
It's been a while since we've seen much news around third party app distribution services. Between TestFlight, App Center and Firebase, it's all wrapped up, right? Maybe not. TestApp recently launched a distribution-focused, cross-platform service for both iOS and Android.
I wish them good luck. It's a tough market!
Firebase seems to be taking over the world a bit, but before you commit to it for your next project read Andrew Bancroft's case for CloudKit. I still think if you're building something truly serious then rolling your own back end is probably the way to go, but I do like CloudKit too.
I'm not sure how I feel about this, but I'm going to try not to judge it before Google get a chance to show what they do with it. Yes, there's a risk that some of these tools will be integrated so tightly with Firebase that they become less useful for those who don't use it, but equally maybe they won't. The Fabric tools never felt like a 100% natural fit at Twitter either, and would they survive the heavily rumoured acquisition by Disney? Who knows. Anyway, I think we have to wait and see what this means for the future of Fabric.
When Apple unveiled DocC two years ago, I don’t think anyone was too surprised to see it produce documentation from source code comment annotations with Markdown formatting.
But that wasn’t all DocC did, and it was a pleasant surprise when we learned it could use Markdown for both navigation structure and long-form documentation to accompany your generated API reference.
No one would have raised an eyebrow if that’s where the tool’s capabilities had stopped. But there was one big surprise left with it being able to produce fully interactive tutorials, like the Apple-authored ones they created to teach SwiftUI. It makes sense for Apple’s internal teams to all use the same tool rather than having a “documentation tool” and a “tutorial tool”, but I still didn’t expect it.
The slight downside is that those tutorials, while beautiful and easy to read, with screenshots that persist while the reader scrolls past multiple tutorial steps, take a long time to create. Would anyone outside Apple be willing to put the work in to make them?
So I’ve been idly keeping track every time I spot one in the wild, and while I’d not call them common, there are still plenty around, and I’d love to showcase a few for you today.
They’re even used to create training/workshop material, which I didn’t expect.
It’s fantastic to see people put time and effort into creating such high-quality tutorials. However, if you just looked through those and felt intimidated, remember that any documentation is better than nothing. Start with API reference documentation, go deeper with Markdown articles, and only consider adding the “icing on the cake” with a tutorial after that.
It’s great to see such a strong start from DocC. This comment is already too long, but I might write about how many packages we see adopting it in the Swift Package Index at some point soon. It’s more than we expected!