Apple recently launched the new Xcode and simulators for development. Included is the new iPhone 5 — called ‘Retina-4′ — simulator. It functions in the same was as the original — now called ‘Retina-3.5′.
You may have noticed that right away, your app appears letter-boxed even if you are using the full bounds of the screen:
[[UIScreen mainScreen] bounds], or similar.
Using the Full Height
The solution involves just one step. To activate the new screen size, simply provide a
Defaultemail@example.com splash image. The image should appear in your Xcode settings under the app info and Launch Images section. The
568 is the 1.0 scale for the new height. So at scale=2.0, the final height of your new launch image should be 640px x 1136px.
Simply drop that into your project and run it. You should see your app take the entire height. If not, make sure you are always using the views’ frame size/bounds instead of a hard-set value.
Passbook is an exciting new feature coming to iOS 6 which has endless possibilities. Creating a basic pass is extremely simple, yet there is much room for customization.
Passbook will be useful in many areas. A “pass” is not necessarily a pass in the traditional sense, because it may represent a ticket, a coupon, a payment card, or a boarding pass. Some common uses include flight tickets, movie tickets, bus or train tickets, store coupons, or store payment cards. Anything which currently uses a barcode may be turned into a pass for Passbook.
When debugging your mobile application, logging can provide critical information. A few problems arise from the simplicity of iOS’s logging interface. The built-in method,
NSLog, is mainly a development tool, but when left in release code it will still be executed. Removing
NSLog calls before release can be a tiresome process, but leaving them in will slow down your application.
Need hot fashions on the fly? We’ve got a solution for you! Karmaloop.com, a Boston-based web retailer, launches an app for the iPhone that allows men and women to browse, share and purchase from over 500 of world’s most popular streetwear brands on the fly. Karmaloop’s app complements its already popular website, which receives over 4.5 million unique visits a month. Highly sought-out Karmaloop houses brands like Vans, WeSC, Converse, Cheap Monday, Puma and Adidas, just to name a few.
Xtreme Labs stepped in to help Karmaloop re-launch the app to bring it to a whole new level of shopping awesomeness.
This app is an example of the ultimate ecommerce solution for retail businesses as they face a changing industry. Customers are searching for new ways to shop at their convenience. The new trend for retailers is to bring the shopping experience to the consumer, rather than have the consumer physically present in the store or surf to the website. Mobile solutions, like Karmaloop’s app, make it possible for business to create new ways to interact with and reach consumers. The store is in the palm of the consumer’s hand.
So what’s hot about this app?
- The High Resolution Images – Zoom in to get up close and personal with items you’re browsing. Or use the apps unique gallery carousel to see items modeled from multiple angles
- Exclusive Deals and Gift Codes – These sweet deals are only available through the app
- Sharing Functions – Show off new purchases to friends with seamless Twitter, Facebook or email sharing
- Streamline Check-Outs – Process your order on the fly through the app to get your purchased goods faster
Next time you have a hankering to shop, simply pull out your iPhone and in a few short taps you’ll be browsing the latest streetwear fashions on the awesome new Karmaloop app!
This article is co-authored by Pallak Grewal and Rohan Bali.
Facebook iOS SDK 3.0 makes it easier for developers to integrate Facebook into their mobile applications. This new release comes with a host of major updates, from
FBSession which lets an app manage the user’s session with ease to a bunch of smaller features like making it easier to create basic API calls to the Facebook OpenGraph. This version of the SDK also introduces blocks for a cleaner handling of various calls to Facebook.
Announcing Cedar target templates for Xcode 4.3.x: Getting started with Cedar has never been easier!
These templates let you quickly add Cedar targets to your iOS or Mac OS X project. It’s super simple to build and install from source now:
git clone http://github.com/pivotal/cedar --recursive && cd cedar ; rake install
If you don’t like building from source, you can also install a build of the Cedar templates from the downloads page – just untar to your home directory.
Using Cedar Templates
Restart Xcode after installing, open your project and add a new target. You’ll find targets for both iOS and Mac OS X. There are 2 types of targets: Suites and Bundles. A Suite target will build your tests as a separate application which you then run to execute your tests. Bundle targets work just like OCUnit testing bundles, providing closer integration with Xcode. If you do create a bundle target, make sure to edit the scheme of your application and add the new target to the list of tests.
Every template comes with a simple example which should run out of the box to help you get running.
ARC: A word of caution
Automatic Reference Counting setting: Don’t use it for your spec targets. Your application is free to use ARC, just don’t use it for any Cedar targets. This is because there is a flaw in the compiler that ships with Xcode (see here for the details, and if you care please feel free to use this information to file a bug with apple).
Have fun speccing
We really hope these changes help you to get started writing specs and spending less time setting up Cedar. If you have any feedback, whether it’s about these templates or something else about Cedar, please feel welcome stop by the discussion group and share your thoughts.
- acceptance testing for iOS: Frank?
We’d like to do happy path end-end testing for an iOS project. What’s the state of the art?
We saw frank: https://github.com/moredip/Frank
- then is a keyword in ruby
If you want your ruby to read like bash:
if true then
puts "For Sure"
This article was first composed by Peter Raboud
Multiple methods of parsing JSON data are available to iOS developers, but it is not clear which of these libraries is the best option. We investigated this problem by benchmarking the performance of several JSON libraries for iOS:
The tests were done by parsing several different-sized sample data multiple times with each of the libraries, and measuring wall time and CPU time as performance metrics. The tests were run on a 4th generation iPod Touch running iOS 5.1 (9B176). Since wall time and CPU time are strongly correlated, with a correlation coefficient of 0.999999, we did not present the CPU time data.
From testing, we discovered that the native method performed the best. The next fastest library is YAJL, which took about twice as long as the native library. Both of these methods only required a single line of code to use, and the native method is even easier, since it doesn’t have any dependencies to import.
One potential issue that we discovered is that the YAJL library can cause issues if using ARC. Due to changes in ARC,
assign are now mutually exclusive properties, which breaks some of the code in
YAJLParser.h. Line 152 reads ”
@property (assign, nonatomic) _weak id delegate;“. Simply deleting
weak seems to fix this problem. While this issue has been open on Github for 7 months at the time of writing, this workaround is the only solution yet discovered, and the author has yet to respond to this issue.
To conclude, the native library is the best choice as far as performance goes, but it can only be used in apps that exclusively target iOS 5.0+. For apps that must provide legacy support, YAJL is the best choice.
Good documentation goes a long way towards, not only helping others understand your code, but also simplifying re-use. Unfortunately, it seems that the moment documentation is written, it’s out-of-date from the code, especially if maintained separately in its own document.
When Sun Microsystems introduced Java, they also introduced Javadoc, which let their engineers, and other Java developers, document APIs “in-line”, next to the method definitions. Javadoc uses a simple markup language, embedding the documentation for a method within a
/** … */ comment block. Typically a Javadoc block starts with a sentence or two describing the purpose of the method or function. The purpose of parameters passed into the method are marked by
@param followed by the parameter name and its description. Finally the comment block ends with a description of the return value, preceded by
@return. This documentation lives in the class interface definition, making it easy to maintain at the same time as the code, ensuring that it remains up to date. The Javadoc tool can easily parse the source files, producing human-friendly, HTML documentation of the library classes.
Gentle Bytes’ excellent appledoc tool brings this easy documentation approach to Objective-C development. Simply comment the methods in your class definitions (.h) and run the appledoc application to compile beautiful documentation that both matches the format of Apple’s framework documentation and integrates directly into Xcode. Claus Broch provides a great blog outlining how to integrate the execution of appledoc directly into Xcode, further simplifying your documentation efforts.
Appledoc provides a simple and lightweight way to document your Objective-C code, making it easier for both you and others to understand and re-use your code.
With the recent release of the new iPad, app resources (images, videos, etc.) will be significantly larger. Apple has raised the 3G app download to 50mb to compensate for the larger images, but it may still be a tight squeeze. This is especially true for universal apps that have to support low and high resolutions of iPhones, iPods, and now the iPads. Often during the construction of an app we will go through many revisions to the UI, moving new assets in and out of the app. In this confusion, there’s a chance that the developer might forget to remove the image as a resource from the project when it is no longer used.
We have written a script to automate the process of finding unused resources:
It’s simple to use, just clone the repo and invoke the script providing a relative path to the project’s working directory. For example:
The script can optionally include or exclude comments, and can be configured to provide a varying amount of output to the console. It recursively searches the provided project directory; looking at various files such as headers, implementation files, and nibs. It’s easy to edit the script to include resources of any given file extension.
There are some known issues, for example,
stringWithFormat:@"%@.png" won’t work. Feel free to fork and please report bugs.
Last August, the iOS developer community discovered a small change with potentially large implications that came with the introduction of iOS 5.0: the deprecation of the UDID. The UDID is a highly used unique identifier for each iOS device; somewhat like a social security number for your phone or tablet.
UDIDs are widely used in the context of creating and distributing ad-hoc, beta builds. However, there have been a number of security and privacy concerns raised when it was found that this identifier was being used for many other purposes.
To address these concerns Apple has given a new alternative, the UUID, and as of late has been urging more and more developers to expedite the replacement of the UDID in their apps. Some reports indicate that Apple is starting to actually reject apps that reference UDIDs.
From the iOS 5.0 release notes:
Deprecated in iOS 5.0
An alphanumeric string unique to each device based on various hardware details. (read-only) (Deprecated in iOS 5.0. Instead, create a unique identifier specific to your app.)
@property (nonatomic, readonly, retain) NSString *uniqueIdentifier
Do not use the uniqueIdentifier property. To create a unique identifier specific to your app, you can call the CFUUIDCreate function to create a UUID, and write it to the defaults database using the NSUserDefaults class.
When making this change, it is important to note the differences between the UDID and the new UUID. The UDID was a unique identifier for your phone that was the same across all applications. It remained constant even when you deleted and reinstalled an application, allowing for the application to still know who you are. Now, with the UUID created through CFUUIDCreate, it is only unique for an app, and on one particular install. Once you delete and reinstall the app, a new identifier is created. If you do need the new UUID to last beyond app deletion and reinstall, the value could be stored in iOS’s keychain instead.
If you would like to know more about the implications that this will have on your app, do not hesitate to contact us for more information.