@objcio: This issue is all about data synchronization and network communication…Here, we will try to help you get a better grasp of the problems involved, with articles about syncing approaches, iCloud Core Data and Documents syncing, custom syncing solutions, and networking in general.
@bjango: OS X’s Color Picker panel has been around for an eternity and is jam packed full of great features. One of my favourites is the ability to sample colours from images.
@jeremywsherman: Internationalization is hard. If you’ve always lived where you have to travel to another continent to encounter something other than your local monoculture (hello, many fellow Americans), it’s even harder. Perhaps it should be no surprise then that everyone gets it wrong. Over and over, I see the same amateur mistakes. Two seconds spent using your app in some locale other than the one you developed in would make you go, “Oh. Crap.”
@mergesort: I’ve been doing Objective-C for almost 5 years (woo!), so at this point I think I have a better understanding than most of Apple’s motivations and intentions, with relation to building the language. That said, recently I’ve been loving working with Go, and there’s a few reasons for that.
The winner of the book drawing is Maksim Pavlov.
Congratulations Maksim! Contact me by email to claim your prize.
Effective Objective-C covers 52 Objective-C best-coding practices, tips and tricks. In a similar manner to Scott Meyer’s Effective C++, Matt provides background information on a concept (why is it relevant), provides code examples (to illustrate the technique) and ties everything together with good explanations.
iOS Developer Tips is proud to announce that we are a Media sponsor of mdevcon 2014, mobile developer conference.
mdevcon is a conference created by mobile developers, for mobile developers. The event includes multiple tracks covering iOS, Android and Windows. There is a wide range of speakers, sure to make for many interesting sessions.
The conference is coming up quickly, March 7-8 2014, in Amsterdam. You can still grab a seat.
NSCoding is a fantastically simple and convenient way to store data on iOS or Mac OS by turning your model objects directly into a file and then loading it back into memory again, without needing to write any file parsing and serialization logic. To save any object to a data file (assuming that it implements the NSCoding protocol), you can just do this:
Foo *someFoo = [[Foo alloc] init]; [NSKeyedArchiver archiveRootObject:someFoo toFile:someFile];
And to load it again later:
Foo *someFoo = [NSKeyedUnarchiver unarchiveObjectWithFile:someFile];
That’s fine for resources that are compiled into your app (such as nib files, which use NSCoding under the hood), but the problem with using NSCoding for reading and writing user data files is that, because you are encoding whole classes in a file, you are implicitly giving that file (with potentially unknown origin) permission to instantiate classes inside your app.
Note: Since the introduction of custom URL schemes, this post has consistently been the top read content on the blog. Although much is the same, there are a few nuances that have changed. This is a re-write of the original post, updated for the latest iOS and Xcode versions.
One of the coolest features of the iPhone/iOS SDK is an application’s ability to “bind” itself to a custom URL scheme and for that scheme to be used to launch the application from either a browser or from another application.
And the winner is … James Cambpell
Congratulations James! Contact me by email to claim your prize.
This week we are giving away a copy iOS Core Animation: Advanced Techniques, written by Nick Lockwood.
This book provides an in-depth look at the Core Animation framework, covering a wide range of topics from layers to physics to visual effects.
I’m still working through the book, however, I will say that I’m impressed at the extent of information provided in just the first few chapters.
Core Animation and the related topics are not trivial. Nonetheless, I found this book to provide a balance of technical information along with good examples. Experienced iOS dev’s should find this to be a good resource to quickly get up to speed.
Unless you’ve been living under a rock, you’ll have probably heard of a little iOS game called Flappy Bird.
Whilst users went nuts over it, the iOS developer community’s response to Flappy Bird was a bit less enthusiastic; many criticised it for its poor implementation and relative crudeness. But though several developers declared that they could have built Flappy Bird in an hour, others quietly confessed that, although they could see it was simplistic, they actually wouldn’t have the first clue where to begin with writing a game for iOS – even one as simple as Flappy Bird.
Games are a hugely popular genre of app, but making games is a somewhat different process to traditional application development. There are dozens of ways to build games on iOS, from cross-platform tools such as Unity, to 3rd party frameworks such Cocos2D, to built-in APIs such as SpriteKit and GLKit. Most app developers have heard of these, but many have never have tried using them.
In this tutorial, we’ll demystify gaming on iOS by building
Flappy Bird Floaty Balloon in a couple of hours, using ordinary UIKit classes that any app developer should already be familiar with. UIKit is not designed for gaming, but as we will demonstrate, it’s perfectly suitable for building a simple game such as this.
The winner of iOS Auto Layout Demystified is…Riley Testut.
Congrats Riley! Contact me by email to claim your prize.
Next week will be giving away a copy of iOS Core Animation: Advanced Techniques, by Nick Lockwood.
The book is now in its second edition, with updates for iOS 7 and Xcode 5.
I purchased the first edition of iOS Auto Layout, and I can say, the style mirrors Erica’s other books: easy to follow, in-depth explanations and well thought out code examples. I’m confident this second edition builds upon the first, providing an excellent resource for mastering iOS Auto Layout.
A common task in Cocoa programming is to loop through a collection of objects (e.g. an NSArray, NSSet or NSDictionary). This seemingly simple problem has a wide variety of solutions, many of them with subtle performance considerations.
The Need for Speed
First, a disclaimer: The raw speed of one Objective-C method versus another is one of the last things you should worry about when programming – the difference is unlikely to be dramatic enough to matter compared with other, more important considerations, such as code clarity and readability.
But not prioritising speed is no excuse for not understanding it. You should always learn the performance implications of the code you are writing so that on the rare occasions when it does matter, you’ll know what to do.
Also, in the case of looping, much of the time it doesn’t matter which technique you choose from a readability or clarity perspective, so you might as well choose the fastest. There’s no point writing code that is slower than it needs to be.
With that in mind, here are the options:
I recently was working on a project where I wanted to display an integer value as a binary string in Objective-C. Once I wrote what I thought were two decent implementations, I was curious to see how another developer would approach the same problem.
I asked Nick Lockwood if he would be up for coding up something similar. Bear in mind very limited requirements were provided upfront. The solution could be C function, a method or a category, and the signature for calling was undefined.
Read on to see four unique variations of how to convert an integer value into a binary NSString object.
Much has been written about managing multiple versions of Xcode. With the release of the Mac App Store, Apple changed the Xcode install process. It’s time to revisit this discussion, including installation of older Xcode versions as well as some tips on managing beta releases.
Prior to the Mac App Store, it was quite simple to work with multiple versions of Xcode, as each release had an option to specify the destination folder during install. No more, installations (non-beta) will overwrite an installed version of an app with the latest release, as each new release is installed in the /Applications folder with the name Xcode.app.
In this post I’ll walk through how I prefer to manage multiple versions of Xcode. If you have another approach, please post a comment.
Deprecated APIs, as you may know, are methods or classes that are outdated and will eventually be removed. Apple deprecates APIs when they introduce a superior replacement, usually because they want to take advantage of new hardware, OS or language features (e.g. blocks) that were’t around when the original API was conceived.
Whenever Apple adds new methods, they suffix the method declarations with a special macro that makes it clear which versions of iOS support them. For example, for UIViewController, Apple added a new way to present modal controllers that uses a block callback. The method declaration looks like this:
- (void)presentViewController:(UIViewController *)viewControllerToPresent animated: (BOOL)flag completion:(void (^)(void))completion NS_AVAILABLE_IOS(5_0);
Somewhere around Xcode 4.3 lldb became the default debugger. I’ve been spending some time learning how lldb differs from gdb and stumbled upon a trick to allow changing the value of a variable while in a breakpoint.
For example, in the code below I print the value of testStr, I then change its value using the expr command in lldb, I then print the value of the string again:
1 2 3 4 5 6 7
NSString *testStr = @"fubar"; NSLog(@"testStr before: %@", testStr); // Set breakpoint here, run the 'expr' shown below // Show testStr again NSLog(@"testStr after: %@", testStr);