Under The Bridge Under The Bridge

Category: Cloud
Offline Networking Management

So we have this new app that synchronizes all its operations with the website backend; and what, what, we ask rhetorically, do you figure the immediate cacophony of demand is?

Why, yes. Yes, it’s “Make checking in work offline!” Of course it is.

Now, 1.0 does cache all the last retrieved data so we’ve made a start on offline operation…

The Many Offline Options for iOS Apps

How to Design Offline-first Approach in a Mobile App

… so in this context, “work offline” is going to be defined as “queue database transactions to be applied to the server once connectivity is established,” as opposed to the current strategy of “call the API and do nothing if it fails”. We’re going to break that into a series of steps:

1) Currently our database transactions are UI state driven, with local changes applied only after online success, with a modal dialog forcing the user to wait. This is expedient, but annoying, and fallible.

So what we’ll do is encapsulate all our transactions into undoable objects, apply them to the local database immediately, and queue them for retry or cancel, ie. undo, if the online synchronization fails. Since having a functioning Undo implementation is a fine idea in any case, and helps us abstract out this rearchitecting nicely. If like us you haven’t implemented Undo recently (like in Swift at all) here’s some good tips on that:

Adding Undo and Redo support to iOS

UndoManager Tutorial: How to Implement With Swift Value Types

2) We’re going to need some awareness of when connectivity is established, to trigger applying these transactions to the server. Alamofire our networking layer has a simple one, implemented like thousands of others on top of ancient code. However, it has its issues … and there is a better option these days (iOS 12+): NWPathMonitor

Network Framework in iOS: How to Monitor Network Status Changes with sample code

Detecting Internet Access on iOS 12+ … now supported in Connectivity along with Solving the Captive Portal Problem. And backwards compatible Reachability support. So that looks like an excellent choice for network awareness needs!

And as an aside here, if you want to prompt people who turn off your app’s mobile data to turn it back on, check out

Handle disabled mobile data setting on iOS

However, for this particular application we can see that being a popular setting seeing as it’s all about foreign travel and all, so we’re not going to fuss about it as only working on wifi would be very likely indeed to be the users’ preferred mode of operation.

Speaking of operations, that brings us to:

3) A serializable and resumable and retryable queue for managing these operations

Right now we have a pretty simple asynchronous Operation wrapper for simple serial queuing of background data refresh operations, not completely unlike the network Operations described here,

Building a Networking Layer with Operations

Download files sequentially using URLSession inside OperationQueue

and as mentioned in the first point we’ll be making their local transactions undoable; but we’re going to need something a little more high powered than a stock memory OperationQueue to handle these, won’t we? Well, there are a number of possibilities mentioned that have various levels of support for persistence and awareness mentioned over in that promises roundup we did long before Combine was on the horizon, but here is one of particular interest:

OfflineRequestManager: Pod for Offline Network Request Management

OfflineRequestManager is a Swift framework for ensuring that network requests are sent even if the device is offline or the app is terminated.

OfflineRequestManager works by enqueuing OfflineRequest objects wrapping the network request being performed and observering the current network reachability using Alamofire. If the app is already online, then it will be performed immediately…

…! If a network-related error is passed into the completion block, then the OfflineRequestManager will retain the request and try again later. Other errors will by default remove the request from the queue, but there are optional delegate methods to allow for adjustment and resubmission if needed.

Realistically, there will likely be some data associated with the request. You also may want to be sure that the request is sent up even if the app is quit or (heaven forbid!) crashes…

Well, that would be … pretty much our exact feature requirements, actually! Hasn’t been updated in a year from Swift 4.0, so we’ll reimplement it in Swift 5.1 and add NWPathMonitor savviness and all, but a modernization is quite a less imposing task than designing from scratch, yes?

… and as a stretch goal, we’ll see about it taking advantage of background tasks too. You check out that new framework?

Managing background tasks with the new Task Scheduler in iOS 13

How to use BackgroundTasks framework to keep your iOS app content up to date?

So definitely, a superlatively up to date network request manager would also take advantage of that for recurring tasks!

Kowalski, Analytics!

So it’s been a little while since we last looked at analytics for your iOS app, and as it happens we have a new one just out that could use some sober second thought on its analysis strategy going forward; let’s take a look at that today, shall we?

Kowalski

 

First off, since you don’t have to do any work to get them it’s always a good idea to keep abreast of the latest developments in App Store Connect App Analytics – especially since there’s a bunch there that you can’t get with any other service! But, since you can’t report any custom events so they’re not very interesting development-wise, we’ll just remind you of the documentation and move right along, to consider in detail the current crop of services that are FREE! and UNLIMITED! that being the tier of service that us scrappy Indies are most interested in naturally!

So, last time we were checking out this analytics thing, the buzz was all about Fabric Answers

The best of Answers realtime analytics is now part of Firebase. New apps should use Google Analytics for Firebase…

Well then. How about that old standby for website centric organizations, Google Analytics? Oh, look they’re shutting that down too this Hallowe’en…

To use the latest generation of app reporting in Google Analytics, you’ll need to install the Firebase SDK. If you do not have a Firebase project, go to firebase.google.com to get started. Once you have completed the setup, return to Google Analytics…

Huh. OK, if you’re tied into the Google ecosystem, or anything that was good it acquired, it seems your choice is very clear. Singular, in fact!

Personally, we’d prefer not to be tied into the Google ecosystem, particularly if we’re not depending on it for anything besides analytics, so we’ll leave the Firebase option off the table as long as possible. Besides, it isn’t completely free, although the free usage limits are generous.

For completely free to the developer, Flurry appears to still be the leader in app support suites, with push and real time analytics and advertising and remote config and all sorts of other goodies these days; come a long way since Peter Farago stopped by to say thanks for our first note on it over ten years ago and now he’s “GM & VP Flurry” at Verizon with a job description of “Making Flurry awesome(r)” so that would seem to indicate that it’s weathered its various acquisitions nicely and continues to be a solid choice going forward.

While we were developing this last project, we tried out Visual Studio App Center and were reasonably pleased with it in general — we didn’t get around to creating any specific events, but even the default session monitoring of App Center Analytics is providing useful information — it’s still maturing, but if you’re tied in to Microsoft platforms or the slowly migrating HockeyApp, this is the support suite for you! Without that, it doesn’t have a compelling use case … aside from being Not-Google. Should you find that compelling.

Another option, if you have a Facebook app as pretty much everyone does these days, is Facebook Analytics where if you’ve linked in the Facebook SDK you can see session info in Facebook’s Event Manager things logged with App Events for iOS. Not actually real time though, and you don’t get the push notifications and crash reporting and so forth of the above suites, so picking one of them is probably what most of us will be interested in. 

Now, there are a veritable plethora of other analytics services out there that don’t meet the FREE! and UNLIMITED! test, any number of which may be suited enough to your particular needs to be worth their investment: here’s a few of the better recentish roundups we looked at putting together post, check them out if you have a budget:

The Apps Have Spoken: Top 13 iOS App Analytics Platforms [2019]

Top 11 Mobile App Analytics Platforms in 2019 (Pricing Included)

Top 20 Mobile App Analytics Tools: Which is the best one for you?

Top App Analytics Tools (2019)

And if you don’t want a service at all but want to host your own analytics, an excellent start on that is this:

Countly Community Edition
Your very own, self hosted and open source desktop, web, mobile analytics server and SDKs

At least it looks like it. We wouldn’t know. We’re not into self-hosting or rolling our own of anything we can possibly get away with not. But if you are, check it out and let us know how that goes for you!

And finally, whichever one of these alternatives you pick first, it’s a solid bet that you’ll be called on to change it at some point, because that’s just the way it always works, isn’t it? Here is a nicely elegant post about creating

A modular analytics layer in Swift

We are going to build a layer that avoids using a static API, puts any backend APIs behind a protocol, uses the power of Swift enums and pairs each event with the pieces of data it needs to contain.

More specifically it should:

  • Be easy to report new and existing events.
  • Allow the data be sent to whichever analytics backend we wish to use, even multiple.
  • Be testable and mockable, allowing it to be an injected dependency.
  • Allow events to be reported from anywhere in the app, but encourage best practices.
  • Have compile-time safety of events and their properties…

Sounds like just about the way we like to put service wrappers around our dependencies yep — so whatever analytics you choose, check that out!

UPDATES:

8 Critical KPIs for Your App and How to Track Them

Assertions in Production for tracking internal errors

SmartlookConsentSDK for getting user consent

Live Photos Is Life

(And there’s your earworm for the day, fellow 80’s kids. You’re welcome.)

So we hadn’t been overly impressed with Live Photos when they were introduced — GIFs with sound, that nothing supports, yay? — and proceeded to assume that would shortly end up on the long list of forgotten Apple multimedia technologies that we were experts in back in the day, so might as well forget it immediately and save time. But perhaps we were a trifle cavalier in that evaluation, looks like Apple’s doubling down on them at least somewhat, got a top level folder for them now:

Live Photos for Developers

Live Photos allows you to relive your favorite memories with movement and sound. Take advantage of the new Live Photos API and let users enjoy these moments in your web app…

API and docs are still Spartan as ever,

PHLivePhoto

Live Photo HIG

Live Photo Editing and RAW Processing with Core Image

but this is new, a library to support web page embedding:

LivePhotosKit JS

Use the LivePhotosKit JS library to play Live Photos on your web pages.

The JavaScript API presents the player in the form of a DOM element, much like an image or video tag, which can be configured with photo and video resources and other options, and have its playback controlled either programmatically by the consuming developer, or via pre-provided controls by the browsing end-user…

and published with npm even. That … hopefully … indicates they’re serious about supporting it then!

So if you have any site that uses photos for anything, take a look at supporting Live Photos as well, now that it’s easy and all!

TestFlight Spreads Its Wings

You catch the latest TestFlight news just now? This looks pretty interesting:

What’s New in TestFlight

TestFlight in iTunes Connect now provides multiple build support, enhanced group capabilities, and improved tester management—making it even easier to test your apps.

Multiple Builds

TestFlight now lets you distribute and test multiple builds at the same time, so testers can choose from a number of builds to test.

Groups

TestFlight groups have changed. You can now do more with them, like create groups of TestFlight users, and each group can test a different build. To get you started, we’ve added all of your existing external testers to the group “External Testers,” which you can edit at any time.

Tester Management

Testers can continue testing a build when it goes live on the App Store, minimizing disruptions. iTunes Connect users can also access all active builds, letting them seamlessly compare different builds and you can easily resend invitations to testers who have not yet accepted their invitation.

Learn more about TestFlight.

Well doesn’t that just sort a whole lot of issues we routinely run into amirite? Sure we can play games with app IDs and icon tagging and whatever, not even going to bother linking to our various posts on tips and tricks for that kind of thing, but this looks waaay easier.

Mind you, we haven’t actually distributed an app using Apple’s incarnation of TestFlight yet, next one’ll be the first. When they first acquired it the no iOS 7 thing was a flat out dealbreaker, and by the time that wasn’t well we’d settled into a Crashlytics centred flow nicely so eh whatever dudes.

First time it crossed our mind hmmm maybe we could rethink that was this post last fall

How Not to Crash #1

Interestingly, these crashes did not appear in our usual crash reporting service, HockeyApp, so it actually took us a while to realize that we had a problem. To be aware of all crashes, developers need to check for crash reports through iTunes Connect or Xcode too…

Well, if we have to check them there, why bother checking other places too? Always like to streamline our process, being awesome DevOps dudes and all. But that wasn’t enough to seriously consider going all in, until a few weeks ago Google gobbled as Google gobbles and we were a tad miffed you might recall

Clearly this is great if you’ve already bought into the Firebase platform, but if you haven’t there’s a bit of thinking to do now, especially for those of us in businesses that Google actively competes with so have a smidgen of trepidation about handing over our collective user profiles and activity. Paranoid, yes yes, but hey paranoids have enemies too.

So that was enough to prod us into actively researching alternatives. In our considered opinion Bugsee is the best out there right now by a spectacular margin, oooh network logs would rock! but oh come on dudes we’re an indie place here (OK, actually these days we’re DevOps at Agoda.com because BANGKOK! come join us we need lots of everything especially iOS, but speaking as Trollwerks here) you actually think we can pay? Heh, that’s cute. And yes yes Dear Reader your favourite is very nice too, but nothing else really struck us as worth the effort to switch to.

But this. This here, this actively solves recurring problems! And far as we’re aware — please correct us if we’re wrong — the only actual downside from a dev perspective remaining with TestFlight is that users can opt out of reporting, and then no doubt those that choose to are the exact ones that would get that one weird crash we’d get grumpies 1-starring us with no way to figure out wtf they’re going on about, which would be … suboptimal. But, oh wait, that problem’s sorted now too, so … what’s left as a practical objection to going all in on TestFlight for your iOS platform needs? Why, nothing we can see!

If there’s anything we’ve still overlooked, please comment, but at first glance our verdict is yep, next project, no Google libs, all in Apple. We’ll update here if any flaws arise in that cunning plan!

Fabric, R.I.P.

Catch the news yesterday? That was a mild surprise:

Fabric is Joining Google

Welcoming Fabric to Google

Although only mild, we grant you, because, well…

Indeed. Clearly this is great if you’ve already bought into the Firebase platform, but if you haven’t there’s a bit of thinking to do now, especially for those of us in businesses that Google actively competes with so have a smidgen of trepidation about handing over our collective user profiles and activity. Paranoid, yes yes, but hey paranoids have enemies too.

Not much out there in the way of comprehensive alternatives for your development deployments left though: for cross-platform development this Visual Studio Mobile Center thing that HockeyApp is growing up into might be interesting, but that looks like pretty much it, really.

‘Course, you could always just go all in on Testflight and let other platforms fend for themselves; it’s the easiest by far, that it’s iOS 8 or later should be no longer a problem in 2017 — if that still is a problem for you, our most sincere condolences — plus we gather that frontloading the binary approval process into the beta distribution is supposed to make the final review go noticeably quicker. That would be a quite acceptable tradeoff indeed for having to get your betas approved; does anyone have any firm statements and/or evidence that using TestFlight does actually expedite final review, or is this urban legend?

And as always, if we’ve missed the beta distribution method of your choice here, please educate us!

Notification Tokenism

So, did you catch WWDC 724 yet? It’s less than 15 minutes, check it out:

What’s New in the Apple Push Notification Service (transcript)

Starting with a review of the HTTP/2 based provider API, you will learn about an important new feature: Token Based Authentication. Learn to connect to APNs using authentication tokens for sending pushes via the HTTP/2 API, relieving you of the overhead associated with maintaining valid certificates.

Ah, yes. Longtime readers will remember various instances of untrammelled joy (where by “joy” we mean “near-homicidal frenzy”) APNs has provided over the years, so this is a very interesting indeed development. Full details were published September 20 at

Local and Remote Notification Programming Guide / Apple Push Notification Service

and announced September 22. So let’s check this out, shall we? Especially as we got the annually dreaded “This certificate will no longer be valid in 30 days.” email day before yesterday, which makes the timing entirely apropos!

Step 1: Oh look, now under certs in the Dev Portal we have this new “APNs Auth Key” option! So add one, and…

Step 2: Read the instructions:

Download, Install and Backup

Download your Authentication Key to your Mac, then double click the .key file to install in Keychain Access. Make sure to save a back up of your key in a secure place. It will not be presented again and cannot be retrieved at a later time.

Step 3: Be confused as the download gives you a .p8 file, not a .key file, and it’s not evident how you get that into the Keychain.

Step 4: Check out the discussion on the dev boards:

It’s a PEM-encoded, unencrypted PKCS#8 file. You can inspect it with openssl pkcs8 -nocrypt -in <your_file.p8>, but you’ll need a newer version of OpenSSL than the one that ships with El Capitan (I’m not sure which version comes with Sierra). I’m not sure how to import it into the Keychain, but I also haven’t run into a situation where having it in the Keychain would be helpful (other than just for storage).

Step 5: OK then, let’s find some service that can use this shiny new .p8 file then…

Step 6: ¯\_(ツ)_/¯ Not much out there yet!

Alright, so we’ll keep working with a cert-based process for the moment then, check for UPDATES! below once we find some. In the meantime, development tools that can work with the shiny newness? Hmmmm … looks like you’re pretty much on your own there too as we write this. Right then, if you know of any token-supporting services or tools, hit the comments section!

If you’re proactive enough to want to help move the development tools scene along, our goto for APNs tinkering for a while now has been Knuff: “The debug application for Apple Push Notification Service (APNs).” along with Knuff-Framework “just add it to your application and the phone will be visible under “Devices”” and Knuff – The APNs Debug Tool on the App Store! Pretty complete ecosystem there and we strongly encourage helping out with it if you’re interested in this space.

If you’re new to this APNs thing, or If you’d simply like a straightforward HTTP page to use for testing, check out this new site PushTry.com to, eponymously enough, try pushing:

pushtry.jpeg

Nicely done tutorials for both iOS and Android, clean and functional; definitely recommend you give that a pushtry. And they’re working on token support too!

Should you be looking to get this on your server side ASAP, a quick look around for projects at least using HTTP/2 APNs, that being kinda the floor for ‘actively maintained’ currently, in a variety of environments turns up these:

VaporAPNS “is a simple, yet elegant, Swift library that allows you to send Apple Push Notifications using HTTP/2 protocol in Linux & macOS. It has support for the brand-new Token Based Authentication but if you need it, the traditional certificate authentication method is ready for you to use as well. Choose whatever you like!”

swift-apns: “Swift Framework for sending Apple Push Notification over HTTP/2 API”

node-apn: “A Node.js module for interfacing with the Apple Push Notification service.”

ApnsPHP: “Apple Push Notification & Feedback Provider”

APNS/2 “is a go package designed for simple, flexible and fast Apple Push Notifications on iOS, OSX and Safari using the new HTTP/2 Push provider API.”

And again, if you have good … or bad … experiences with any particular piece of APNs server kit, let us know!

UPDATES:

docker-swift-apns: “A collection of Docker images to build APNS providers in Swift”

Push Notifications and Local Notifications – Tutorial

Push Notifications Tutorial: Getting Started

NWPusher: “OS X and iOS application and framework to play with the Apple Push Notification service (APNs)”

iOS remote push notifications in a nutshell

Core Data iSunny iDays

Why “iSunny iDays”? Why, because iCloud is going iAway! That’s no surprise for those of you paying attention since 2014 at least, but now it’s sorta-kinda official. As usual, Michael Tsai has a good roundup:

The Deprecation of iCloud Core Data

… When installing the Xcode 8 beta, I noticed that all of the symbols related to iCloud Core Data were marked as deprecated in macOS 10.12 and iOS 10, with the comment “Please see the release notes and Core Data documentation.” Strangely, the Core Data release notes and What’s New in macOS 10.12 documents make no mention of this. What’s New in iOS 10 simply says that “Several NSPersistentStoreCoordinator symbols related to ubiquitous content” have been deprecated.

I asked on Twitter what was up, and no one seemed to know. No one had anything nice to say about iCloud Core Data, either, though no doubt many developers still rely on it. I hoped that all would be explained in today’s WWDC Session 242: What’s New in Core Data. Alas, reports are that absolutely nothing was said about iCloud in the session…

No need to panic immediately, they’re not pulling a Parse on us or anything like that … yet … but you certainly would be well served to adopt an alternate solution if Core Data iCloud sync appears anywhere in your technology roadmap. Apparently the mothership has something in the works, but if you have an immediate development need for Core Data cloud sync, there’s one clear choice:

It seems clear that the way forward is Ensembles, unless you want to write your own sync engine or wait for Apple to announce one. I hope that the deprecation will spur more of the community to coalesce around Ensembles.

Indeed. We’ve been vaguely aware of it since the 2013 announcement, but we’d managed to miss until now that there’s a commercial with source access Ensembles 2 that includes CloudKit and other backends, whilst the original remains open source on GitHub. And in the likely event that you agree that seems a clear way forward, this is a good time to jump on board:

The Core Data Sync Deprecation Sale

If you move to Ensembles now, you not only get the usual support, documentation, and source code, you also get it all at half the standard price. The sale will continue until macOS Sierra is released later this year.

Whilst that sync thing is still up in the air, Core Data itself moved forward nicely this year, most notably in that standing up your stack is now much more straightforward:

Concurrent Core Data, Now Easier Than Ever

Core Data has a popular opinion of being hard to use, especially in concurrent environments. Why is that the case? First, it truly is complex because it solves a hard problem. Second, until WWDC16 Apple haven’t really said how to best set up the Core Data stack. There were many options, each with its own issues, that we had to choose from.

That’s why I’m super happy that things get clearer in iOS 10 with the introduction of NSPersistentContainer…

We’ve been pretty happy with JSQCoreDataKit for our Swift projects, but soon as your deployment targets allow, there’s all sorts of win with the new stuff here!

And as a final note, if you’re all excited about the new playground stuff — and who isn’t? — check out the explorations here:

Using a Core Data Model in Swift Playgrounds

Is this a great time to be alive, or what?

UPDATES:

Building The Perfect Core Data Stack

Cleaning up Core Data Fetch Requests

Seam: “Seamless CloudKit Sync with Core Data”

Core Data on iOS 10, a brief overview with an Example

A Swift Implementation of the Core Data Stack Using NSPersistentContainer

Moving Core Data Files

Kuery: “A type-safe Core Data query API using Swift 4’s Smart KeyPaths”

The Laws of Core Data and rebuttal

Working with Codable and Core Data

Preferred schema settings for Core Data debugging

Core Data Debugging in Xcode using launch arguments

Painless Core Data in Swift

How a Model Controller works with Core Data in Swift

A Wild URL Appeared!

This is an interesting article about using Swift pattern matching for routing deeplink URLs:

URL Pattern Matching

The majority of URL routing libraries use a pattern syntax that can match each element of a URL’s path in one of three ways:

  • Equality: Path element must match the pattern expression
  • Value-binding: Path element can be anything at all, and will be made available in a parameters dictionary
  • Wildcard: Path element can be anything at all, and will be discarded

… There are a few reasons I don’t much like this approach:

  • The pattern matching is abstracted away using special syntax.
  • The parameter name userId is repeated and stringly typed, so it’s susceptible to typos.
  • parameters[“userId”] should never be nil, but the compiler doesn’t know that, so we must force unwrap or add a guard statement.

As it happens, Swift’s built-in pattern matching can be used for each of the three pattern types…

Proceeds to walk through the design process of a few abortive approaches, and ends up with the URLPatterns library here:

I prefer this approach to the approach taken by most URL routing libraries for a few reasons:

  • It’s simple to bypass URLs and open a deeplink directly, e.g. by calling DeepLinker.open(.Home).
  • The pattern-matching code is no longer in a third-party library, which makes it easier to debug.
  • The pattern-matching code leverages Swift’s built-in pattern-matching, which means it can be customized and extended.
  • The pattern-matching and routing processes are separated into two steps. This provides an override point if needed…

Neat! For even more niftiness, check out the Generator approach in URLs and Pattern Matching mentioned in the comments.

And while we’re discussing routing, if you want something more conventional, this looks like a good choice:

JLRoutes: “URL routing library for iOS with a simple block-based API.”

  • Simple API with minimal impact to existing codebases
  • Parse any number of parameters interleaved throughout the URL
  • Wildcard parameter support
  • Seamlessly parses out query string and fragment parameters and passes them along as part of the parameters dictionary
  • Route prioritization
  • Scheme namespaces to easily segment routes and block handlers for multiple schemes
  • Return NO from a handler block for JLRoutes to look for the next matching route
  • Optional verbose logging
  • Pretty-print the whole routing table
  • No dependencies other than Foundation

Looks like a sweet dropin to handle just about everything you’d want, that!

UPDATES:

Simple Deep Linking in Swift

iOS: How to open Deep Links, Notifications and Shortcuts

Fire Up The Base

In case you’ve been floundering about what to do service side since Parse dropped the BaaS, here’s something you’ll want to take a look at — Google has seriously levelled up Firebase with unification and new services:

FireBaseServices.png

Firebase is expanding to become a unified app platform for Android, iOS and mobile web development. We’re adding new tools to help you develop faster, improve app quality, acquire and engage users, and monetize apps. On top of this, we’re launching a brand new analytics product that ties everything together, all while staying true to the guiding principles we’ve had from the beginning:

  • Developer experience matters. Ease-of-use, good documentation, and intuitive APIs make developers happy.
  • Work across platforms. We’ll support you whether you’re building for iOS, Web, or Android.
  • Integrate where possible. Firebase has one SDK, one console, and one place to go for documentation and support…

That’s a lot of features there, with free to minimal pricing until you’re scaled up looks like.

Particularly interesting is that they’ve put at the centre there this new analytics service,

At the heart of Firebase is Firebase Analytics, a free and unlimited analytics solution. Analytics integrates across Firebase features and provides you with unlimited reporting for up to 500 distinct events that you can define using the Firebase SDK. Firebase Analytics reports help you understand clearly how your users behave, which enables you to make informed decisions regarding app marketing and performance optimizations…

Custom audiences can be defined in the Firebase console based on device data, custom events, or user properties. These audiences can be used with other Firebase features when targeting new features or notifications.…

As it happens, we’d just been planning to get around to picking an analytics platform for the next project, as it’s been a hella long time since we last surveyed that space, or even updated with notes on the general consensus:

If marketers are going to be using analytics tools, Mixpanel or Localytics. If developers want data to play with, Flurry.

Since then, Flurry was absorbed into Yahoo Mobile Developer Suite, Localytics and Mixpanel appear to be doing fine although now we have actually accurate marketing analytics from Apple,

App Analytics is Apple’s very own analytics platform. It lives right inside of iTunes Connect. Announced at the WWDC in summer 2014, it launched finally in spring 2015 and just recently added support for tvOS apps. One might say just “another” analytics platform like free solutions from Flurry/Yahoo Mobile, Google or Facebook, but App Analytics finally provides reliable data nobody else can (Spoiler: App Store impressions, referring websites, attribution)

You should read all the rest if you aren’t familiar with it, but since it requires no technical implementation there’s no support decision to be made there so we can move on. Let’s check a couple curated collections:

Apptamin’s App Analytics Tools Round-up

iOS Dev Tools’ Analytics section

awesome-ios’ Analytics section

Well, clearly if you have trouble reaching a decision, ARAnalytics is for you:

ARAnalytics is an analytics abstraction library offering a sane API for tracking events and user data. It currently supports on iOS: Mixpanel, Localytics, Flurry, GoogleAnalytics, KISSmetrics, Crittercism, Crashlytics, Fabric, Bugsnag, Countly, Helpshift, Tapstream, NewRelic, Amplitude, HockeyApp, HockeyAppLib, ParseAnalytics, HeapAnalytics, Chartbeat, UMengAnalytics, Librato, Segmentio, Swrve, YandexMobileMetrica, Adjust, AppsFlyer, Branch, Snowplow, Sentry, Intercom, Keen, Adobe and MobileAppTracker/Tune…

And if you’d prefer to just follow the herd, looks like they’re heading for Twitter these days:

Answers Named #1 in Mobile Analytics for iOS

Back in May, Answers was ranked as #2 on iOS and #3 on Android in the mobile analytics space by SourceDNA, the world’s largest database of mobile app intelligence. Since then, we’ve been building out new features like Answers Events, which helps you track specific actions and events in real time, to better understand how users are behaving within your app.

Today, we’re thrilled to tell you that Answers has now been named the #1 most implemented mobile analytics SDK on iOS — just five months after it was named #2!

So no lack of innovation in that space, definitely. If you decide to jump on the new Firebase bandwagon, be sure to let us know how it goes for you!

UPDATES:

Getting Started with Mobile Analytics

28 Metrics That Matter for Your App

Firebase 101, a simple todo list app

Creating a Backend for Your iOS App Using Firebase

Google’s Firebase developer platform gets better analytics, crash reporting and more

Introducing Firebase with Swift 3: Login and Sign Up; Using Firebase to Integrate Facebook Login in iOS Apps

Keep an eye on the competitive developments over at Microsoft: The Next Generation of HockeyApp

Firebase Tutorial: iOS A/B Testing

Fabric lands top spots for app analytics, stability, and monetization

Well, that makes the decision process simpler: Fabric, R.I.P.

Marco Arment:

iOS devs: Any decent self-hostable crash reporters, analytics packages?

I think it’s wise to consider bringing this in-house these days.

Quick-Chat: “Real time chat app written in Swift 3 using Firebase”

Back-End as a Service for Mobile Apps

Implementing Push Notifications on iOS with Firebase

Using Firebase Cloud Messaging for Remote Notifications in iOS

Advanced Firebase For The Win

Firebase Costs Increased by 7,000%!

Get Started With Firebase for iOS Apps

Scratching the Firebase services with your iOS app

Why Firebase sucks

Swift Mushroom Clouds

Our friends at DZone have a new guide out worth reading for a grand overview of the cloudscape these days:

DZone’s 2016 Guide to Building and Deploying Applications on the Cloud

The question isn’t whether or not to use the cloud; it’s when and how. This guide contains everything from building 12-factor apps to hiring full-stack engineers. Navigate through a 90+ cloud solutions directory and start coding right away. Dive into the research findings from 700+ developers on *aaS adoption, cloud security models, container use (including Docker), and more.

Historically we’ve tended to have a fairly detached regard for the state of the cloud, it being so far over our heads and all, but we’ve been contemplating the idea of moving into full stack engineering due to the way Swift clouds are mushrooming all over the place. No, seriously, mushrooming; just check out the current list from awesome-ios:

  • Perfect – Server-side Swift. The Perfect library, application server, connectors and example apps.
  • Swifter – Tiny http server engine written in Swift programming language.
  • CocoaHTTPServer – A small, lightweight, embeddable HTTP server for Mac OS X or iOS applications.
  • Curassow – Swift HTTP server using the pre-fork worker model. [And check out the rest at github/kylef!]
  • Zewo – Venice based HTTP server for Swift 2.2 on Linux
  • Vapor – Elegant web framework for Swift that works on iOS, OS X, and Ubuntu.
  • swiftra – Sinatra-like DSL for developing web apps in Swift
  • blackfish – A fast HTTP web server based on Node.js and Express written in Swift
  • swift-http – HTTP Implementation for Swift on Linux and Mac OS X
  • Trevi – A powerful Swift Web Application Server Framework Project
  • Express – Swift Express is a simple, yet unopinionated web application server written in Swift
  • Aeon – Aeon is a GCD based HTTP server for Swift 2.
  • Taylor – A lightweight library for writing HTTP web servers with Swift
  • Frank – Frank is a DSL for quickly writing web applications in Swift
  • Kitura – Web framework and HTTP server for Swift by IBM
  • Swifton – A Ruby on Rails inspired Web Framework for Swift that runs on Linux and OS X
  • Dynamo – High Performance (nearly)100% Swift Web server supporting dynamic content.

Personally, we’re inclined to agree with people who like the look of Swift Express

Being perfectionists, we took the best from what we think is the best: power of Play Framework and simplicity of Express.js

Express is an asynchronous, simple, powerful, yet unopinionated web application server written in Swift…

…but we may just be biased because the authors are from Lviv. We were there a couple years back, it’s pretty cool.

Here’s some helpful introductions to server-y Swiftness:

Hello Server Side Swift

Getting Started with OpenWhisk Server Side Swift

Swift + Kitura on DigitalOcean

swift-for-backend-SNAPSHOT-2016-03

And some help that’s not server specific, but likely to be of interest to living out on the bleeding edge here:

Cross-platform Swift “A talk about writing Swift targeting multiple platforms. Given at App Builders 🇨🇭 2016.”

Practical Cross-Platform Swift

Swift And C: Everything You Need to Know

swiftenv: “Swift Version Manager — allows you to easily install, and switch between multiple versions of Swift.”

Let us know about your experiences with any of these frameworks!

UPDATES:

Building Slack Bots In Swift

Why I’m Not Using Swift On The Server (Yet)

Server Side Swift vs. The Other Guys — 1: Input

Try out Swift packages in the IBM Swift Sandbox

Super Spectacular Server-Side Swift!

BluePic: “is a sample photo sharing application for iOS that shows you how to connect your mobile application with Kitura, Bluemix services, and OpenWhisk actions.”

Swift on the Server – Where Are We Today?

Cross-Platform Swift by Boris Bügling

Building Your First Web App in Swift Using Vapor

Swift on Linux

Build an end-to-end Swift app with Watson APIs

Tailored Swift – coming soon to a cloud near you

Serverless Swift: Running Swift Code on Amazon Lambda

Building a Production Server Swift App: Lessons Learned

SwiftyBeaver/SBWebsite: Logging in server-side Swift; Deployment of a Swift Vapor App to the AWS EC2 Cloud

My Thoughts on Server-side Swift: Routing

Kitura/iOS: Running a Web Server on your iPhone

Swift… Swift everywhere

Getting Started with Server Side Swift: 1.0; Getting Started with Server Side Swift: 1.2

Deploying Server Side Swift to Linode

SCADE: Cross-Platform mobile development with Swift ; Swift for cross platform client & server side development

Server-Side Swift Live Coding

Server-Side Swift: Comparing Vapor and Perfect

Current Features & Benefits of the Top Server-Side Swift Frameworks

Building a Swift Web API

Vapor 2: Less code, more power.

Errors On The Server

Swift Cloud Workshop – Swift Microservices: “How to deploy Swift micro-services using Docker and Kubernetes, with scaling, monitoring and fault tolerance using the Kitura server side Swift framework.”

Kitura Tutorial: Getting Started with Server-side Swift

Kitura Stencil Tutorial: How to make Websites with Swift

Server-Side Swift: Kitura vs Vapor

Vapor 3.0.0 released

Swift for Android: Our Experience and Tools

Type-safe APIs with Swift gRPC

Supporting Push Notifications with Vapor 3

Watermarking photos with ImageMagick, Vapor 3 and Swift on macOS and Linux

Building a Scalable URL Shortener Service using Swift with Vapor3