Welcome back for the third post of our blog series on how we build mobile apps at Collective Idea. In the last installment we covered basic project setup. This time, we’ll discuss our first steps in fleshing out the application.
Now that you know what your mobile application will do and look like, it’s time to get your various environments set up. Here’s our list of things we check off at Collective Idea for creating an iOS app.
Developing a mobile application that works on both iOS and Android takes a bit of work. Here are some best practices to get you going.
What seemed like a simple-reskinning turned into a much more involved project. It’s codebase that’s sat dormant for a few years, and that posed difficulty finishing tasks in the time we originally thought it would.
The following covers a few of the lessons we learned. That way you can be aware of pitfalls the next time you have to update a legacy iOS application.
How can our test suite tell us when a certificate expires? We’ll show you.
Realm is a good alternative to CoreData for your iOS apps. Setting up properties to be stored in the database is as simple as defining them in a model. But what about those properties that you don’t want persisted?
Databases don’t come with complex field types like an image. That doesn’t mean we can’t store them in our database anyway.
Apple’s introduction of Swift to the Cocoa development toolbox has created a buzz amongst Cocoaheads. The language is flexible and lends itself to new patterns which traditionally Objective-C programmers are excited about. I got excited about a pattern that emerged while working on a new version of the Dead Man’s Snitch iOS app:* using Swift structs to store application configuration information*.
A few months ago, we built an iOS App for Dead Man’s Snitch. The drive behind making it a native application was to take advantage of the Apple Push Notification System. When the App went live to our customers via the App Store it quickly became clear that we were missing notifications sent from Dead Man’s Snitch.
One of the hurdles you have to overcome when building an app like Downside is how to handle network messages. Apple provides several different ways of adding networking to your apps including GameKit and the new Multipeer Connectivity framework in iOS 7. Each of them require you either send or receive an NSData blob.
I’m extremely excited to introduce Downside, our first foray into building a game for iOS.
Sure, making apps that communicate with a server somewhere is interesting, but what about your creative side?
Last week HipByte released RubyMotion and although I was originally skeptical, I’ve grown to really like it.