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.
We’ve all heard developers say it: “I’m a terrible drawer” or “I’ve got no design skills”. Perhaps we’re even guilty of saying it ourselves - I know I am. But after attending this year’s Swipe Conference I now subscribe to the opinion that this is no longer acceptable. We are all responsible for the design of the app we are building; developer, designer, tester, or producer: every member of the team is accountable for helping shape the app’s design and interactions.
When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder. More specifically, why should I use it and how it could possibly benefit my iOS development - given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then.
Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it's now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I'm now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn't always the case, which leads me to my key message here:
If you're new to iOS development, don't touch Interface Builder until you are capable of building UIs programatically.
I thought it was about time I should put together a simple guide on using Jenkins to build your iOS application - and for those of us that use the awesome testflightapp.com website for managing our iOS app distribution for testing, I have included details on creating a Jenkins job to publish the latest successful artifact to testflightapp.com.
Not that long ago I gave a demo in which I showed how it was possible to control iTunes from my laptop using native Ruby code.
This was all possible because of a great little gem called rb-appscript.
rb-appscript is a really neat Ruby to AppleScript bridge...
As a relative newby to the world of Cocoa programming (on the iPhone in particular), I have spent some time trying to understand if and when you'd use a run-loop instead of launching a separate thread. I was unable to find any definitive answer on...
After having gone through the pain of installing Ruby on Rails on my MacBook Pro running Tiger (OS X 10.4) I was pleased to see that Leopard (OS X 10.5) ships with Rails 'pre-installed' and ready to go.
So, after I upgraded my installation on Friday night I was perplexed when trying to run my Rails apps. Why was it broken?
In the end, it turns out there were several problems.