BlogAugust 17 2018
Continue reading... August 10 2018
Many of our apps are mirrors, at least at some level, of a website. The interface might use iOS or Android specific UI or layout that is optimized for smaller screens, but the data the user is interacting with is the same accross platforms. Navigation for these 2 platforms however are fairly different. On the web you rely on the browsers back button heavily. In iOS you might use a navigation controller or a cancel button on a modal, but you have to be intentional about how things are presented and intentional about rolling back those transitions. For instance, if you just kept pushing modal view controllers on top of each other to go back to “home”, you would end up with a large stack of views and view controllers all taking up memory indefinitely.
These worlds have to interact though. There has always been ways (sometimes hacks) to move between a web page and the same content in an app. First there were custom url schemes (
myapp://) then smart app banners and finally Apple gave us...
Continue reading... August 3 2018
Years ago I read Even Faster Web Sites: Performance Best Practices for Web Developers by Steve Souders. It was a simpler time, and the best practices for web development were still being figured out. Almost 10 years later, the advice here seems obvious. Our tools take these practices for granted and impliment them by default. For instance, the idea of bundling all of your JS and CSS into single files for the entire site. It might not be obvious, but if one page uses JS file 1 and 2, and another page uses JS file 2 and 3, the best choice in most cases is to combine all the JS files into a single file and request it on ever single page. That’s how Rails and Webpack, along with many other tools work out of the box.
The book had many great gems of wisdom, but one of the driving assumptions of the book was that http requests have a lot of overhead. HTTP connections are limited to 1 request and response at a time. So if you request 3 files from your server, that connection will ask for the...
Continue reading... July 20 2018
For many if not most apps these days, some kind of login and authentication is required. Ideally your app should have some kind of benefit without an account. Something to give users value before they make the commitment of creating an account, but for some services that just isn’t possible.
Managing this state can be a bit more difficult for iOS apps than web sites though. A website can just redirect to the login page if it realizes a user isn’t logged in. But for iOS, we need to maintain a single view hierarchy.
The naïve approach
For years I used an approach similar to this: setup your UI for a logged in user, making that your root view controller. Then, whenever the user logs out or their session expires, show a modal login screen.
There are a couple of problems with this approach:
First, you have to account for multiple parts of your code trying to show the login screen. At first this can be simple: when your app launches check if the user is logged in and show the login screen...
Continue reading... July 13 2018
In part 1, I outlined why Serverless architecture, and Lambda in particular, could be a really great solution for “server side” Swift, and how to get the bare minimum of a hello world example working. But it takes more than getting a process to run to use Swift as a backend. In part 2, I’d like to build on that work and work towards a more production ready environment.
Run and done isn’t enough
We’ve been using the same technique AWS recomends for all of their non-native languages, which is to start a new child process on every request. This is ok for one off jobs like processing an image, but if we want to use Swift for our entire function bodies, once we start connecting to things like databases and using cachable resources, that will start to be a bottleneck. While Lambda encourages you to think about a function as handling a single request/job, for performance reasons the process is (sometimes) left running between excecutions.
The result will be quit a bit more complicated than...
Continue reading... August 22 2016
A guide to using Swift with AWS Lambda
Server side Swift has come a long way in the almost 3 years since Swift was made open source and available on Linux for the first time. Still, progress has been slow as the ecosystem develops. In particular, there is still no clear winner for a http server framework.
But what if we could have server side Swift… without the server? A serverless server side Swift?
You may have heard the new buzzword in tech lately: “Serverless”. Like “The Cloud” it still just means someone else’s server. It’s the next step in evolution after services like Heroku. Services like AWS Lambda handle the entire server mechanics, except for the actual business logic, which the call functions. Instead of building a server that handles the logic of the http protocol, you simply define the output for a single endpoint. And even better, because each endpoint is it’s own function, you can even use different languages for different endpoints. This is a great way to sneak Swift...
Continue reading... June 23 2016
Many languages today either come with a full featured dependency manager, or have a canonical one that everyone uses and is supported universally. A dependency manager does the work of downloading and integrating any dependencies (3rd party libraries/frameworks) including dependencies of those dependencies. Unfortunately, Apple doesn’t seem to accept the existence of 3rd party code1. This has led to several options for incorporating external code into a project. I have personally used all of these options in shipping apps2.
All of these options apply to macOS, watchOS and tvOS, but the history of all these options were largely driven by iOS not supporting dynamic frameworks like macOS.
A few weeks ago I got a bug report from my tester. I quote: “Animated GIFs don’t animate. This is inconsistent with the web experience—and it’s just not fun.” We definitely want our app to be fun! But we never really built animated GIF support into our web app. It just kind of happened. If you display a GIF on a web browser, it’s going to animate it. It’s just what it does. It would be harder to keep them from animating.
GIFs are awesome, obviously. Emoji may have taken over the world, but when people start to look further, to take their playful graphics to the next level, they turn to dem moving pictures that have been popular for decades. Sure there are more efficient formats available, and higher quality formats are pushed by Apple. But the common GIF still dominates in one form or another across the entire internet.
In iOS 8 Apple introduced support for custom keyboard extensions. As with many of their APIs, it is clear that they had one idea for them, but developers immediately...