DevJuice
Latest
DevJuice: Promotion from the Trenches
TUAW Dev Juice talks with Mac developer Lyle Andrews, who agreed to discuss his real-world experience launching applications. He'll be sharing tips and hints about practical app promotion skills. I want to thank you for taking the time to talk to me and to TUAW readers. The reason I asked you here was because I think you have a really compelling story to tell and tips to share. You're a small developer who's achieved some exciting success in Apple's App Stores, yes? Can you tell us about your background and your products? Yes, I've been coding since I was 12, have been through 14 languages, have a degree in philosophy, and am a veteran of the dot.com wars where I ran over 60 projects including a dot.com startup and a Fortune 500 web deployment. My project history can be seen here. I've been moving into consumer software development and have two large projects in the works, Ynnis Myrddin, an interactive film about Merlin, and MetaView, a 3D market vizualizer. When the Mac App Store started operations I decided to write a few small apps to learn its dynamics: Tempest - a video lightning screensaver, Fireworks HD, another screensaver, and Network Logger, an active network monitor. Network Logger is currently selling in the top 6%, Fireworks HD in the top 2.5% and Tempest! in the top 2% of their categories on the US store. I first came across your work when I reviewed your Fireworks app just before New Years. Can you share how that process of pitching and reviewing worked from your end and talk about how the TUAW review affected your sales? Getting Fireworks HD reviewed by Apple was straightforward compared to getting the first screensaver on the store, since the App Store doesn't sell screensavers directly. I tried numerous ways around this restriction, including zipping up the saver and storing it in a shell app's bundle or having the app download the saver. After half a dozen rejection cycles one of the Apple reviewers took pity on me and suggested adding a download link that the user could click on in the app. This puts the onus of responsibility on the user, gives them control, and with that approach I was able to get approved and onto the store. Being very much a developer I have the classic indie tendency to just keep coding and sit around wishing that someone was promoting my apps full time. This does make the exposure the App Store affords very attractive. I do occasionally send out press releases and hold free promotions on the store. For Fireworks HD, I knew getting some exposure for New Year's Eve was important so I emailed an editor at TUAW about the possibility of a review right after Christmas. I saw that as a win/win since that was the app on the store most appropriate for New Years' Eve at the time. Fireworks HD was named Mac App of the Day on Dec 27, 2011 and the sales rank responded immediately and dramatically, moving from around rank #100 up to #4 in Top Paid Entertainment within a day. On New Year's Eve itself Fireworks HD was on the Top 10 Entertainment charts of 13 countries. Over the next few weeks Fireworks HD trended down as expected but happily ended in a higher average range which has persisted for five months to date. Can you tell me about some of the strategies you've used in-store for helping your apps stand out from the competition? I know you mentioned something about icons when I first started talking to you about doing this interview. What other suggestions do you have? I anticipated your question, so here is a very long list of suggestions. Pop out. Your icon has to pop out. Look at the primary category you will be listed in, imagine you are in the top 200, what similarities or appearance trends can you find in the app icons, and how can you break them in a way that draws attention and invites a click. A number of people have told me that they clicked on Network Logger just because of the icon. Something about it just makes you want to click it whatever it leads to. Keep it short. This indicates that you are confident that the customer is going to like your product if they are interested in general. It shows you feel like you don't have to say that much to make the sale. This is true with new clients as well as products. A long description starts to feel like an apology after awhile. However, some things are complex and merit a longer description. Conciseness is the actual metric. How can you say the most with the least words? Keep it Plain. Plain descriptions with minimal self-praise and adjectives are trusted more by App Store customers than overinflated rhetoric. Focus on Strength. Best in class in some way? Definitely say so. If nothing is the best, should you be aiming higher? This is true for Fireworks HD, it is in some ways a silly app I built to test out the store, but if you need beautiful 100% realistic HD fireworks for your event that don't repeat in sequence and work when no network connection is available, there is nothing better available for Mac than Fireworks HD. Be a master of the obvious. While there are many great naming strategies, if you can name a product after its product category, you have a home field advantage. With "Network Logger" for instance, the genus is instantly obvious, the customer just needs to know the species. They click, they are coming to see you, you are the category, the sale is yours to lose. Don't sweat bad reviews. They are going to happen, if an app has merit it will tend to sell anyway and time will equalize things. Tempest has been in the top 10 in Spain in Paid Entertainment for many weeks despite having only two reviews there, both 1 star. Follow or lead the market, either way know which you are doing. Leading the market is much more challenging, and can be much more rewarding. Can you come up with a way of systematizing a part of the raw unordered universe and create a new class of human activities? If you succeed your glories will be sung in Valhalla. Following the market can be safer and is often more lucrative. Can you rethink a better way to handle a common human activity? Use resonance awareness. There are some things you just know are going to resonate with a particular audience, fireworks, lightning, beaches, white rounded kitchen appliances...resonance awareness is really a diverse skill set it pays to hone. We know Steve Jobs actively developed this skill set throughout his life. Understand need. You need their need. What fundamental emotions are driving the user as they use your software? A desire for order? Curiosity? Love? A desire to conquer? Every activity has a number of emotions that are commonly associated with it. Knowing what your audience is experiencing and wants to experience emotionally is the foundation of an evolving relationship. It's not just woven into the advertising, the product is built around it. In conclusion, these things are all simple in theory, but if the execution sounds simple, think again. The student sees the simple and thinks it simple, the master sees the simple and thinks it profound. I hope one day to be such a master myself. There's been a lot of negative talk over the last few years about the App Stores being too saturated, that small guys can't make a living at it, that there's no room to break in. What would you say to that? I would say that oversaturation is bound to happen given the gold rush mentality, but overall the App Stores have been really empowering to smaller developers and that virtue will be recognized if one persists. The bar is higher now and development and marketing effort have to reflect that. The App Store gets far more traffic than my own web sites and provides more than just sales exposure; the review system has sort of opened up a dialog between me and my customers that wasn't there before. There are a lot of nasty reviews on the US App Store but internationally they are much more measured; they all make you tougher (better at taking criticism), and your app better. Being able to say you have apps on the store also has a certain social cachet these days that's valuable in personal and professional situations and that opens up new opportunities. Lyle, thank you so much for taking the time to talk today. I'm hoping that your experience and your insights will help inspire other developers, especially those just getting started. And if you're still reading this post and you like this kind of developer-centric coverage, please let our editorial team know. Drop a note and tell TUAW that you care about dev topics.
DevJuice: Should I develop cross platform?
App Store. Android. Amazon. If you're a developer, there are lots of possible venues competing for your attention. So which one is worth your time and energy? I turned to Avatron Founder and CEO Dave Howell for the answer. Avatron makes Air Display, a popular app that allows you to use a mobile device like an iPad or phone as an extra display for your computer. When you're on the road, it's nice to be able to offload a Twitter stream, for example, onto a secondary screen so your laptop can be dedicated more to your work. Air Display is now available across a number of platforms, including the following stores: Apple iOS App Store (iOS) Apple Mac App Store (Mac) Google Android Market (Android) Amazon Appstore (Android) Samsung Apps (Bada) Intel AppUp (Windows netbooks) Given the time investment, the overhead, and general work involved in developing cross platform, where has Avatron seen its strongest sales? You won't be surprised by the answer: in the iOS App Store. Like many other developers, Avatron has found that the App Store delivers customers and product interest in ways that other platforms have been unable to match. Howell lays out the sales as follows: iOS App Store: Strong sales Mac App Store: 1/10 of the sales of the iOS App Store Android Market: 1/2 of the Mac App Store sales Samsung Apps: 1/5 of Android Market Amazon App Store: 1/10 of Android Market Intel AppUp: "4 copies in over an entire year" and Howell bought one of those copies. Each store has its strengths, weaknesses, and quirks, but Howell is clear about one thing -- No matter how we App Store developers complain, "iOS is the most painless of the bunch. And this is coming from a developer whose latest iOS app was pulled by Apple without any credible justification." Avatron retired Air Dictate this January. "Our most recent submission of Air Dictate did not break any rules, or use any private APIs," Howell said, discussing the background of that situation. "Apple pulled it because it bizarrely claimed that apps that "relate to Siri" are infringing Apple's Siri trademark or copyright. I sent them the email addresses to three Apple IP lawyers so the app review team could get a tutorial on what exactly trademarks and copyrights are, but my helpful suggestion have proved fruitless so far." Compared to other stores, however, Apple's App Store offers the simplest road to market and the best logistics. "The latest move by Google requires Android Market sales to go through Google Wallet. No more PayPal, Zong, or Boku. And now Android Market is called Google Play," Howell explained. "I can't keep up with the thrashing. And Google still offers no way to give out promo codes, or even to purchase a copy of an app for somebody else. Apple's way, way ahead in this kind of logistics." Howell pointed out that Amazon remains US-only. "Amazon does let us buy gift cards for people, which is nice. As long as they're in the US and they don't mind getting their apps through Amazon Appstore. Amazon's review process is no faster than Apple's, and strangely it's much slower to get an app approved for Amazon's own Kindle Fire than for other devices. So their own customers get our apps later than everybody else." Despite low sales in Samsung Apps and Intel AppUp, Howell reports that the recruiting process and submission was pleasant enough. So should you invest time going cross platform? Hopefully Avatron's experience gives you a hint as to the market possibilities. If you like this kind of developer-centric coverage, please let our editorial team know. Drop a note and tell TUAW that you care about dev topics.
TUAW Bookshelf -- The Business of iPhone and iPad Development: Making and Marketing Apps
A recommendation by Chris Forsythe pointed me to Dave Wooldridge and Michael Schneider's book "The Business of iPhone and iPad Development: Making and Marketing Apps" (Apress, 2011). A practical primer on creating your business plan, the book offers advice on topics diverse as protecting your intellectual property and why testing and usability is crucial for app success. It's an easy read (admittedly a little choppy in the writing at times) but I found it full of valuable advice, especially for anyone who is thinking about entering the App Store ecosystem but hasn't jumped in yet. You'll find coverage about competitive research and being realistic about what it takes to succeed in App Store. From pricing your app (free or not), monetizing free apps (iAds and other in-app opportunities), to Freemium models (leveraging in-app purchase), a large part of the book centers on understanding how to sell. A final series of chapters covers marketing issues, like creating pre-release buzz and press releases. If I have any criticism, it's that the authors sometimes went a little too technical (there's actual code in the book and their intro recommends a programming background) for a general business text. The advice here is perfectly valid for people hiring tech personnel, not just one-man dev shops. There's also a bunch of lists that seem to be there to increase the page count rather than offer a practical value to the reader and the ebook table of contents was set up in an odd way (you have to click on page numbers, not section names). Those are minor quibbles. I wish the authors had spent more time on the strength of the book (creating a business plan) and less on technical implementation details. That said, there's plenty of good, solid advice and you should not be scared away from purchasing this title if you're not a programmer. [Full disclosure: Steve Sande and I are writing Pitch Perfect, which talks about how to pitch your app for reviews and has some (but not much) topic overlap with this book.]
DevJuice: Sim Launcher updated
Landon Fuller of the Plausible Labs cooperative has just updated simlaunch, a github project that allows you to create iOS Simulator application bundles that launch from the desktop. This utility helps developers to share builds for testing, for promotion, and for fun that run on the Mac without need for hardware, special signing permissions, or ad hoc provisions. Although I contributed to the original project, all the updates were performed by Landon and all kudos and thanks should be aimed in his direction. Simlaunch is released under the MIT license (which is similar to BSD).
DevJuice: Apple begins unique identifier crackdown
The Verge writes that Apple has apparently begun to crack down on apps submitted using the now deprecated UDID (unique device identifier) APIs that allow developers to track individual devices. The programmer interface used to return an alphanumeric string unique to each deployed device. It was built out of a hash of the unit's serial number and other internal details. Apps that use the uniqueIdentifier API will automatically be rejected as this policy rolls out to its full complement of review teams. Instead, developers are directed to create unique identifiers specific to applications. Those identifiers can then be stored securely in the device keychain and retrieved regardless of application uninstalls/reinstalls. Although some developers have turned to using other approaches to track devices (for example, using the unit's MAC address), it's clear that Apple does not approve of any device-specific user tracking. For now, in-store apps that use UDIDs do not seem in danger of being yanked. The policy seems to apply to all new and updated apps, however. This may be the knell of doom for my Ad Hoc Helper app. Not sure where I'm going to go with that. If you have suggestions, drop a note or leave a comment.
DevJuice: ShipIt! provides customizable image resizing for multiresolution development
ShipIt!, currently on sale for $0.99 at the Mac App Store, offers a simple utility for resizing multiresolution images. Its suite of standardized image formats (such as 512x512 iTunes artwork, 57x57 iPhone icons, and 72x72 iPad ones) ensure that you can create consistent elements from your core art. Drag your art onto the app window, choose a destination and the formats you wish to export to and the app creates the resized elements. As utilities for a buck go, ShipIt may save you a bit of time if it fits into your development flow. I found its user interface to be a bit crude, with the step-by-step process at the bottom of the window not really working for me. I would have preferred to see more state information onscreen. When you pick the default output folder in "step 1", that directory is not visible anywhere onscreen. I also wish the export file types were integrated into the main window instead of floating. As the floating window is, it cannot be resized. This means you can't just have all the elements visible on-screen at once. What's more, the checkboxes didn't act in a standard OS X way -- they sometimes resisted attempts to uncheck them if they were the sole item selected. In the end, ShipIt! seems to have the right idea but could use work on how it gets you to that place.
DevJuice: Can I move Xcode off my main drive?
Dear Dev Juice, Now that Xcode 4.3 is supposed to live in /Applications, can I move it off my main drive? I used to have it on my secondary, because I have a fast SSD as my primary. Also, where are all the files located, like the simulator? John Dear John, At over 3 GB, the new Xcode distro is big, but are you sure you really want to mess with the App Store management, which depends on apps residing in /Applications? We gave offloading a try, moving Xcode onto an external USB disk and symbolically linking it into /Applications. It seemed to run fine and we had no problem creating, compiling and archiving apps. Not sure if this is a super-great idea, though, especially when upgrades come down the line. Our wild guess is that at any upgrade, App Store could overwrite the symbolic link and you'll have to manually move it off the drive again. As for the "files," I assume you're talking about the executables like iPhone Simulator.app (which can be found in /Applications/Xcode.app/Contents in the Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/ subfolder) rather than the data files that are stored in /Users/youraccount/Library/Application Support/iPhone Simulator. In /Applications/Xcode.app/Contents/Applications, you'll find some of your old favorites like Icon Composer and FileMerge. Utilities like git, gdb, and nm are now in the Contents Developer/usr/bin subfolder. Older items such as RezWack and SetFile have moved into the Developer/Tools subfolder. Happy Developing!
Dev Juice: The Art of Readable Code
"The Art of Readable Code" by Dustin Boswell and Trevor Foucher is a fairly short work at under 200 pages, but it addresses a topic near and dear to many developers' hearts. Littered with cartoons and code samples, it's meant to convey the basic philosophy of creating well-structured code that helps document itself. You can read about naming variables, laying out programmatic structures consistently, knowing what's worth commenting about, and more. There's a lot of useful information scattered within, and many of the examples and illustrations are quite good. Unfortunately, the writing does not match up to the quality of the information on offer. I wished the authors had slowed down a bit, better motivated the reader regarding points they were making, and spent time to explain the "why" in greater detail. The book feels rushed and offers a surfeit of passive voice and odd constructs. This is a shame, because the authors had a winning concept. A book about superior communication skills in code should have presented those same skills in its writing. The material here will probably work well as a support to seminars, which can easily use the structure, examples, and illustrations independently of the written text. "The Art of Readable Code" costs US$34.99 for a print version, $27.99 for ePub, and $38.49 combined. It is available from O'Reilly Books.
Dev Juice: New localization tool simplifies multi-language development
Does multi-language Cocoa or Cocoa Touch development drive you nuts? With so many strings files and a need for high precision, you're not alone. A new application called Linguan may help simplify your work. Linguan ($4.99), from Drobnik KG, transforms the way you edit localization files. Instead of selecting individual translations from your lproj folders, Linguan allows you to open your entire .xcodeproj project at once. It provides a unified interface for managing localization tasks across your project. The developers, including Oliver Drobnik and BytePoets, have done a terrific job in analyzing exactly how you get your job done. Linguan tries to help you translate everything, and translate that precisely just once. Linguan checks to make sure you have provided translations for each localizable token across all supported languages. If your PRINT_BUTTON_LABEL appears in the French and English localizations but not the Swedish one, Linguan alerts you. Another thing this app checks for is duplicate tokens. This occurs for many reasons. You may use similar items on multiple screens and enter duplicate names by accident. Or when you use the NSLocalizedString macro, some developers are confused by the role of the second parameter, the comment. The comment is used solely for self documentation and does not differentiate two otherwise identical tokens. Linguan catches these duplicates regardless of why they were inserted. Because you'll likely want to contract out for translations, Linguan allows you to add these custom comments to each of your tokens. This does two things. First, it provides self-documentation as to how you're using each token in the application, and second, it allows you to better communicate that usage to your translator. When you export your tokens, you can include both the comments and a source language translation, (e.g. DEL_CONF, Deletion Confirmation, "Do you want to delete this item?") so the translator receives the best possible summary of the token usage. Linguan also has a few more tricks up its sleeves. It allows you to add new tokens to existing translations when you update your app with more features. There is a search box, where you can enter any token or translation word and it will search across all its source files. This returns tokens that match either in translation or token name. If you're working with many translations at once, Linguan's Wizard mode will simplify your workspace to display just one source and one destination language. Finally (and importantly) it presents all its tokens as a single list, regardless of the file that token originated from. Since most apps provide support in multiple files including Info.plist localizations, and localizations for Game Center, etc. this allows you to use consistent translations throughout your project. I asked Drobnik about support for localized images. He replied that he'll be adding support for these in future versions but he wanted to focus on text for his 1.0 release. Linguan is currently available for $4.99 at the Mac App Store.
Dev Juice: When should you use out-of-app Settings?
Dear Dev Juice, I've heard all the lectures and I understand that the discoverability of third party prefs in the Settings app is near zero. I also get that it's now best practice that developers should put preferences inside applications with custom screens. I'm writing to ask this: what use cases you see where devs should be using settings bundles instead of in-app prefs? Thanks in advance, V Dear V Settings bundles allow you to move options away from users, creating a virtual wall between optional features and day-to-day use. The most common scenarios for this include kiosk apps, app diagnostics, and legal disclaimers. When using apps in public presentation, such as at trade shows or conferences, you don't want Joe Q. Public exploring a "little too far" while using your app. Moving settings prefs out of the app and into Settings helps ensure that curious users won't inadvertently trigger behavior or modes outside of your desired use scenario. What goes in Settings stays in Settings. Settings also provides a great place to enable remote diagnostics features. Again, the idea is to prevent the user from casually entering privileged debugging modes. Doing so typically allows collection of advanced diagnostic information to help resolve technical issues. Tech support personnel can easily walk the user through the steps needed to enable (and later disable) these elements. Placing toggles in Settings instead of the app itself ensures that users are unlikely to stumble across them or enable them in error. The most common use of Settings bundles remains, however, as a place to enshrine all legal declarations associated with the application. Those motivated to explore will discover any number of disclaimers, copyright ownership listings, etc. Placing these in Settings helps declutter the app and provides a unified location for any lawyers who need to look up licensing details. Happy Developing!
DevJuice: HockeyApp improves crash reports, beta testing
You may be familiar with the well-respected TestFlight beta distribution service. Now, HockeyApp has arrived on the scene to give TestFlight a little competition. TUAW sat down with its developer to discover what the service might mean to you. Like TestFlight, HockeyApp offers a core beta over-the-air distribution service. This includes managing testers, invitations, and beta recruitment. But the service goes beyond that. HockeyApp also adds advanced crash tracking to the mix. As a developer, the first part of fixing any problem is discovering what that problem is. HockeyApp helps you collect, manage, and understand crash reports so you can better improve your apps. HockeyApp includes an open-source framework that you embed into your applications. It allows your apps to collect crash reports -- both during the beta period and after App Store deployment. HockeyApp automatically symbolicates the crash reports and it groups similar crashes together, giving you a higher level overview of problem areas within your apps. Symbolication enables you to associate program symbols with crash reports collected by the HockeyApp framework and by App Store. Instead of the hexadecimal addresses normally supplied by the crash report, symbolication translates information from the app's .dSYM files to meaningful labels. Integrating the framework allows you to know exactly in which classes and methods, and at which line number your apps crashed. The website provides a complete reporting solution. That's where you can view statistics and analyze your crashes. Plans start at $25 a month, supporting up to 5 developers and 25 apps at a time. Premium plans grow from there for more heavy-duty development operations. If you're a small independent developer (up to 2 developers, up to 5 apps), you can take advantage of HockeyApp's limited time $10/month Indie Plan. Remember this: iTunes Connect collects just a fraction of your app's crashes. HockeyApp's developer promises his service will help you localize where your crashes are happening, so you can improve your app's reliability. Better reliability means better App Store ratings, and better ratings mean better overall sales. Want to learn more? Visit the HockeyApp feature overview page.
Dev Juice: Automatic Reference Counting
Dear Dev Juice, I'm so confused. Is ARC Automatic Reference Counting or Automated Reference Counting? And is it Manual Retain and Release or Manual Reference Counting? Help a guy out. Paul W. Dear Paul, Let's separate those two questions because there's a cut-and-dried answer for the first, but not for the second. ARC refers to the new LLVM Objective-C automated memory management scheme. With ARC, you can focus more on your code semantics, leaving many of the memory issues to the compiler. Without a doubt ARC stands for Automatic Reference Counting. You can confirm this for yourself by visiting the official Technical Specification page at http://clang.llvm.org/docs/AutomaticReferenceCounting.html. As for the MRR/MRC issue, the use of Manual Retain and Release remains far more common than Manual Reference Counting. An informal survey of a popular developer forum shows that MRR cites outnumbers MRC ones by an approximate factor of three. That doesn't mean the question is settled. Both phrases are used (albeit not as acronyms) in the technical specification documents. Greg Parker of Apple uses MRC in this archived language development discussion list post. What do you use? Add your vote to this poll and leave a comment to explain why. %Poll-69262% Thanks, Tim Burks
Dev Juice: Help find me a standalone property editor
"Dear Dev Juice, With Lion and new xCode 4, Property List Editor is missing. Opening xCode to just be able to edit a plist file is not what I want. So my question is how do you edit your plist files ? Do you know an alternative to xCode 4? Thanks. Thierry" Dear Thierry, If you don't mind converting your property lists to XML format (plutil -convert xml1 filename.plist), you can always use TextEdit to make quick changes. However, it sounds like you're looking for a third party GUI solution. Daniel Jalkut helpfully pointed DevJuice to PlistEdit Pro. A $29.95 shareware application, PlistEdit Pro offers a standalone property list editor. Developer Brian Webster told TUAW, "PlistEdit Pro was originally written in a fit of frustration over how bad Apple's editor was. They eventually updated it around Xcode 3.1 or so, and it was much improved, but then as you saw they pulled the standalone version with Xcode 4." In addition to basic property list editing, PlistEdit Pro also offers a preference file browser, which scans through your user defaults library for easy browsing, adds scriptability for automatically modifying plists, and supports extended search, replace, and undo features. Know of any other third party standalone GUI property list editors? (As opposed to plusutil, which is command-line only...) Leave a note in the comments.
Dev Juice: Help me leverage Lion-only features
Dear Dev Juice, I'm part of a tiny company developing iOS apps. We're about to develop our first Mac OS X app. There are many cool new features in MAC OS X Lion and we'd like to take advantage of these. However, this would mean only people on Lion could use our app... Do you think most people have upgraded to Lion? Or do you think we'd be ignoring a lot of potential users still on Snow Leopard? Gareth Dear Gareth Lots of users have made the jump to Lion but lots more have not. Rather than jumping on the Lion bandwagon completely by providing a Lion-only application, consider conditional coding instead. Conditional coding allows you to offer certain features only to Lion users while ensuring the application remains both 10.6 and 10.7 ready. This solution allows you to build your application for the greatest number of users. Make sure you clarify in your marketing text that certain features are Lion-only so you don't tick off either Apple or your user base. Here are a few conditional coding hints. Check for properties using key/value coding. If valueForKey: returns nil, the property is not available in Snow Leopard. Check for classes using NSClassFromString(). Code around non-existent classes in Snow Leopard by disabling features or removing inappropriate options. Check for selector compliance using respondsToSelector:. When newer APIS are supported, objects will report that they respond to those selectors, letting you call them without crashing the program. You may generate compile-time warnings about unimplemented selectors unless you use work-arounds like performSelector:withObject:. If you really want to go hard core, you can build NSInvocation instances directly. Happy Developing!
Bit.ly announces iOS 5 SDK
Are you an iOS 5 developer? Have you paid up on your membership and accepted the NDA agreement? If so, bit.ly is opening up a new iOS 5-specific SDK. The new SDK allows iOS apps to integrate branded bit.ly shortcuts into the previously-announced new Twitter services. Branded shortcuts include TUAW's in-house aol.it links, for example. Due to iOS 5's pre-release status, you must apply directly to bit.ly (drop them a line at api@bitly.com) and clarify your NDA-status in that e-mail.
Dev Juice: Help me generate unique identifiers
Dear Dev Juice, Can you help me generate a unique identifier for my iOS apps? I don't want to rely on using UDIDs anymore. I'd say why but then you'd have to shoot me. Watm-ever Dear Watm-ever That sounds dire. Let's avoid the violence and focus on the Core Foundation. Here you go. If you're not using ARC, then you'll need to autorelease uuidString rather than bridging. You'll probably want to store your new ids into the keychain to allow them to persist. Happy developing. Update: Readers ask if this approach will persist between application reinstalls. Yes, as I originally posted, it will if you use the keychain. It will not persist with system re-installs if the keychain is wiped and not restored from a backup. Can you use the MAC address, yes -- but it looks as if Apple wants you to stay away from device-specific information.
Dev Juice: What's the deal with k for constants?
Dear Dev Juice, What's the deal with the k in #define kFilename. Is it German? Does it stand for konstant? What gives? Pure Fusion Dear Pure Fusion, The k prefix seems to originate in a naming system called Hungarian Notation, developed by Charles Simonyi at Xerox PARC. The idea behind this system is that the name of a variable should reflect its semantics. Wikipedia offers a sense of these naming conventions, such as arru8NumberList, meaning the variable is an array of unsigned 8-bit integers. Apple follows a similar but more practical convention. Like the original Hungarian Notation, it encodes opaque types, but it does so with a distinctly Apple spin and without all the silly made up non-obvious naming bits like "arru8". As you've already noted, Apple's "k" prefix indicates constants. Typically, the k prefix is followed by type, followed by a more general indication of the item's use. A typical Apple symbol, such as kCFCharacterSetWhitespace can easily be broken down as k (constant) + CFCharacterSet (opaque type) + Whitespace (unique role). Hungarian Notation's goal of encoding semantics into symbols has gone in and out of fashion over time. Some devs love it, others hate it. Most fall in the middle, as does Apple's usage. Being able to instantly identify the role of a symbol as a constant is a win, but a mindless adherence to pedantry in unnatural naming can become a stumbling block. Fortunately, Apple seems to have chosen its path well and its naming schemes are easy to follow while remaining semantically rich. Happy developing!
Dev Juice: Help me use less hard drive space for Xcode
Dear Dev Juice, I have a small SSD drive on my iMac. Got some tips on how to offload Xcode to my USB drive instead? Jaames C. Dear Jaames, You can install some but not all of Xcode to a secondary drive. You'll still end up using about half a gigabyte, but that's a sight better than the multiple gigabytes you'd normally occupy. On the Custom Install Screen (right after you agree to become a centipad), set your install location to Other using the folder pop-up. Navigate to your USB and "Choose" a folder there. After installing, there's more you can do to save room. Open Xcode Preferences > Locations and set your Derived Data, Snapshots, and Archives folders to live off your primary drive. You'll also want to move your documentation (which can take many GB all by itself) as well. Open any class reference in the Organizer, and then right-click > Open Page in Browser. Allow the page to open. Its file:// URL will show you where your documentation is currently stored (normally in /Library/Developer/Documentation). Use symbolic links to move that material to the USB drive. There are more tweaks you can do (move your simulator home, mess with ~/Library/Developer as well as /Library/Developer) but they tend to produce fewer gigabytes for greater effort, so aren't recommended. Happy developing!
Dev Juice: Help me recover my beta partition
Dear Dev Juice, I was in the Lion beta program. Now that 10.7 is about to release I want to reclaim the small partition I added to my laptop that I was using to test it. How do I do this? Shawn Dear Shawn, Disk Utility (/Applications/Utilities/Disk Utility) makes it easy to recover OS partitions assuming you have a standard scheme where you partitioned off a chunk of your drive to host the beta. Assuming you did just that, you'll have a primary partition occupying most of your disk, and a secondary partition after that. Back up everything you can, especially on the second partition. Boot on your primary partition that you have now updated to Lion. Open Disk Utility and select your hard drive (not the partitions under the hard drive) and open the Partition tab. Your layout should have the primary partition on top, the secondary below it. Select the secondary partition and delete it by clicking the - (minus) button. Make sure you read the messages that Disk Utility presents you. You only want to remove the secondary partition, you do not want to affect the primary. If you get any message other than something like 'this will only remove the secondary partition and leave the primary unaffected', stop and re-group. Otherwise, go ahead and perform the removal. (You did backup, yes?) Next, resize your primary partition to reabsorb that extra space. Edit the Size field by entering 9999 GB (or whatever). When you press return, Disk Utility will automatically change that to match the actual available space. Click Apply. It can take several minutes for Disk Utility to verify and apply the changes. But it is able to make the changes (as it did with the original partition) in-place. You will not need to reboot afterwards, although you may want to just for sanity's sake. Good luck and happy developing!
Dev Juice: Help me set up a multiperson dev team
Dear Dev Juice, We have a 3 man dev team with the iOS developer program (as a small company plan) and we are getting ready to move up to Xcode 4 once Lion is out to the public and the have a stable sdk. What is the best way to set all of our systems so we can each build for adhoc distribution instead of just one of us being able to? Thanks, Brandon Dear Brandon, You can easily build for Ad Hoc on more than one machine at a time. Just export your developer provisions and certificates from Xcode's organizer. Click Export Developer Profile, enter a password that you will remember and verify that password. Save the file to a convenient location such as the desktop. You will generally have to enter an administrator password during the process to allow Xcode to access your local keychain. Once created, you can transfer this profile file to another Macintosh system and import it through the same Xcode organizer screen. You will be prompted for the password. Once imported, just do the same build-and-archive, sign-with-the-ad-hoc-provision building of IPAs on the remote installations that you would do at your home system. Happy Developing!
