I recently had the opportunity to work for a client who wanted to develop what they termed "app indexing". What they meant by this was that they wanted their users to be directed into a specific screen of their iPhone app when they tapped on a particular Google search result. Put differently, they wanted the user to feel as if Google had returned search results specifically for their iPhone app.
They also wanted to be able to send out links via email, SMS or other marketing channels. If the app was installed, opening such a link on their phone would result in the user being taken to the relevant points in the iPhone app. If the app wasn't installed then they would just be taken to the mobile website.
The way this is achieved is through what Apple refer to as "Universal Links". In this post I'm going to discuss how we implemented Universal Links at a client of ours, some of the obstacles we faced, and how we overcame those obstacles.
In June 2015, Apple announced at WWDC that they were open-sourcing the Swift language and its runtime libraries. On December 3rd that year they made good on their promise. In this post I'd like to talk about why this is significant, particularly for server-side developers.
Passwords have become such a pain in the neck. Switching between different apps and websites you will usually find different password security policies. One site will inform you no more than 10 characters, other a 6 digits pin. While some other sites will insist in making you change your password every 15 days, and so on.
Why does this have to be so complicated, and hard to manage? Wouldn't it be so much easier to use something that you have as a key instead of having to remember so many different passwords across a plethora of different sites!?
Well, there is something that most of us have. Something we were born with. Something we use every single day. That is our fingerprint. Each fingerprint has a unique pattern that can be used as key. In this blog post, I'll talk about my experience of playing around with Apple's Touch ID.
After the most recent WWDC, most iOS developers aren't talking about cool new iOS 8 features or APIs. Instead, they're talking about a whole new language: Swift. Yes, you heard right - a whole new programming language. How exciting it is!
Apple has been working on Swift secretly for a few years. It is a modern programming language that takes the strengths of other popular languages (for example, Python) and avoids the bad things about Objective-C (for example, poor manual memory-management and awful block syntax). As Apple declared, it’s Objective-C without the C. Not only this, Swift is also able to access the Apple Cocoa Touch framework and share the same LLVM compiler as Objective-C, so they can be seamlessly mixed in a same project.
Now you might be just like me, wondering why Apple would introduce a new language for iOS and Mac OS programming. Let’s walk through some most exciting parts of Swift to see if we can find a reason.
I was recently lucky enough to get a hold of a couple of sets of Bluetooth low-energy beacons; three Estimote beacons and a set of five Kontakt beacons. Whilst the Estimote beacons sure looked a lot fancier, I was keen to see if it was all just for show, or if they truly were a superior product. So I got to work putting them through their paces by conducting some controlled experiments to test their behaviour. Throughout the rest of this post I'm going to discuss the results of these experiments and conclude with some observations on their real-world usefulness for providing proximity-based services.
Problem solving is a major aspect of software development, there are often many different solutions to a problem and a good developer will strive for the most simple without compromising maintainability. However, there are certain times when there’s simply no elegant way to solve a problem so you end up writing what’s commonly referred to in the industry as a hack. You probably won’t be proud of it and you might even have committed the code under a pseudonym so no one can git blame you, but however ugly, the hack still solves a problem and the next thing you know, you’re being asked to write a blog detailing its every hideous crevice.
Recently we released an iPhone app to the iTunes appstore which contains consumable products that can be purchased by a user. I want to share with you some of the pain we encountered when the app went live, and what errors we came across when configuring our server from sandbox to production.