DevJuice
Latest
DevJuice: A quick review of Effective Objective-C 2.0 by Matt Galloway
London-based Matt Galloway, a regular presence on Stack Overflow, has published Effective Objective-C 2.0. A collection of 52 "specific ways" to improve your coding for Mac and iOS, this book provides a valuable collection of handy state-of-the-art tips that will appeal to all developers both established and new to the field. It's a concentrated collection of wisdom with immediate and practical payoffs. From blocks to memory management (yes, even in the ARC age, you still need to know this stuff) to literals, the book is packed with helpful explanations, suggestions and directions. It is not a long book. Although I reviewed the e-book, I estimate there's about 180 pages of actual content, but what content is there is extremely rich. I found easy-to-follow explanations and tight sample code. My favorite bits were the "Things to Remember" bullet points that peppered the end of many sections, with their must-know tips. The book sells for US$18 for Kindle and $32 in paper format over at Amazon. Although some will read it cover to cover, I found myself picking it up, reading a section and putting it down better informed than I had started. It's a great book to sit next to you at your desk, to read a bit from when taking a break from coding. Recommended.
DevJuice: StickyJots for iOS developers
StickyJots provide a low-tech way for you to brainstorm iOS app interfaces. Dave Caolo asked me the other day whether we had covered them before and I was pretty sure we had not. These pretty kits start at US$20 for the faux iPhone, $35 for the tablet and $50 for the "everything kit." Sure, they're not cheap, but they are quite lovely, and I bet they'd make a great gift for the developer in your life. Plus, they might even help you design the next great app. Further details and an online store are found at the StickyJots site.
Dev Juice: Using your tech support incidents
I find it a constant puzzle as to why so relatively few developers take full advantage of technical support incidents. Two incidents are included with your annual developer license. Additional incidents cost just US$50 each, which you buy in two-packs. Using Incidents You'd think that at just $50, a price that's lower than most billable hours, developers would be all over support but, many never end up using them: Others carefully hoard them for the most pressing cases: Resolution Tech incidents don't always have happy endings. In some cases, they get back-burnered without a satisfactory resolution. Other developers report that they have never experienced more than a 48-hour turnaround. Incidents may be credited back if it's discovered that an issue: was due to an Apple bug, should be handled as a feature request, needed to be passed off to another department or simply could not be resolved: While you were initially charged a technical support incident for this request, we have assigned a replacement incident back to your account. Developer Support To use an incident, go to the Apple Member Center and click the Technical support button. The website lists all available support incidents on a per-membership basis. Click the Request Support button to use an incident, or Buy More to add new ones. A panel at the bottom of the page lists your tech support history. When submitting a new request, you provide background on your hardware setup, the issue you're working on and the steps to reproduce it. Beta Software Do note that DTS does not offer tech incidents for beta software. Instead, you should visit the Apple dev forum site and hope that you get some help there. (Most common support response at dev forums: "Please file a bug report or feature enhancement.") Other Avenues WWDC labs in some ways can be seen as a weeklong unlimited tech incident, should you be fortunate enough to attend, and do take note of the technical evangelists for topics. You can often reach out to them outside of the normal tech incident channels. Just be aware that they'll help guide you to appropriate technologies; they cannot and will not help you debug your code. Want to share your tech support stories? Got other suggestions for finding Apple-supplied help? Drop a note in the comments and share.
DevJuice: Third-party MobileDevice framework debuts
It is way early days yet, but the SDMMobileDevice project is now available publicly on github. Meant to provide an open-source, public alternative to Apple's private MobileDevice framework, this OS X project enables you to detect attached iOS devices and communicate with them. With it, you can query connected devices for their software and hardware configurations, communicate with services, access sandboxed applications and perform file transfers and application installations. Developer Sam Marshall is hard at work at toughening up the codebase (it's still early alpha) and providing a more intuitive, delegate-based Objective-C approach to using it.
DevJuice: Sneak peek at Learning Core Data
Today, I got a sneak peek at a very early version of Tim Roadley's Learning Core Data. Expected to publish late November, this book by the Australia-based iOS developer introduces Core Data for those entirely new to the subject. Like other books in Pearson's "Learning" series, the Core Data volume grows around a single project (a grocery shopping tool) that expands chapter-by-chapter. What starts off as a very basic database grows to include photos ("It would be great if you could take a photo of that obscure brand of coffee you love so much."), cloud support and web service integration. The chapters break down sensibly, with big topics like performance tuning and searching each given their proper due. I found Roadley's voice pleasant to read (although he does suffer a tiny bit from modal auxilliaryitis) and I enjoyed the material I read through. It was immediately practical and usable, with good day-to-day tips scattered throughout. I'm hoping to give this volume a more thorough reading once it publishes, adding it to my "to read" pile. If you'd like an early look at this book for yourself, it's available now on Safari Rough Cuts. The book is available for pre-order at Amazon.
DevJuice: Record UIViews with Glimpse
Glimpse offers an open source library from iOS Developer Wess Cope. It enables you to create QuickTime videos from your UIViews. The library records animations and actions, collecting screen shots over time, building a movie from the results. The API consists of two calls: one to start recording, one to stop. An optional completion block processes a file URL after wrapping up the recording. The project is surprisingly simple. It consists basically of an AV Foundation asset writer (for creating the QT movies) and a wrapper. There's no reason you couldn't use Glimpse for store deployment, for recording gameplay or similar tasks as well. Glimpse is perfect for internal testing -- especially if you want to see how test subjects interact with different view layouts. (Cope's related Variant project helps execute those tests.) Got an open source project you think deserves some DevJuice love? Drop a note into our feedback form.
DevJuice: About that Xcode beta...
A few things you should note about yesterday's Xcode beta release... First, new sizes and naming updates apply to asset catalogs. Here's my latest list of what I believe you need to be building on a per-app basis for icons. No, none of this is documented anywhere. I also believe there were no changes to launch images. AppIcon40x40@2x~ipad.png AppIcon40x40~ipad.png AppIcon29x29@2x.png AppIcon60x60@2x.png AppIcon29x29@2x~ipad.png AppIcon76x76@2x~ipad.png AppIcon29x29~ipad.png AppIcon76x76~ipad.png AppIcon40x40@2x.png Second, pay special care to the beta API diffs -- especially anyone doing view controller layout. I just spent 4 hours updating a common pattern throughout several books of sample code. Finally, is it just me, or is that the ugliest Xcode update ever?
DevJuice: Adding warnings for TODO and FIXME comments
A clever post from deallocatedobjects cropped up on IRC on Friday, and I thought I'd share its wisdom. The post discusses how you can add a custom build phase to automatically show TODO and FIXME comments as warnings in your Xcode 4 (and later) projects. It takes very little work. Select a target and choose Editor > Add Build Phase > Add Run Script Build Phase. Paste the following bash script in: KEYWORDS="TODO:|FIXME:|\?\?\?:|\!\!\!:" find "${SRCROOT}" \( -name "*.h" -or -name "*.m" \) -print0 | xargs -0 egrep --with-filename --line-number --only-matching "($KEYWORDS).*\$" | perl -p -e "s/($KEYWORDS)/ warning: \$1/" According to the write-up, credit goes to "Tim" on the Cocos2D forums. Thanks, swillits
Adventures in Google Cast development: Day 1
Google's developer preview SDK for Google Cast -- the streaming technology that's powering the Chromecast hardware -- is up and running. It looks like adding Google Cast support will be ridiculously easy with little coding overhead for anyone who wants to jump on the bandwagon. Although the Chromecast stick we ordered here at TUAW will take a couple of weeks (at least) to arrive, the iOS SDK is already live and an iOS-specific project can be found over at Github. It consists of an app that more or less runs (you may want to comment out the bits about the playProgressSlider) and transmits arbitrary media to a Chromecast receiver. Unfortunately, as far as I can tell, you can't immediately use the receiver HTML on your local network to test transmission. Google writes in its Xcode README: Getting Whitelisted: App IDs and receiver location. You will have to be whitelisted as a developer before you can specify your own App ID and receiver URL, or test the included receiver. For whitelisting instructions, see https://developers.google.com/cast/whitelisting. You send along details about your testing device for whitelisting for your app. In all, it's a bit disappointing that you can't just simulate a receiver for immediate development and testing -- assuming I'm reading all the pages correctly -- without whitelisting a receiver URL and an app. Once you have a receiver URL set up and whitelisted for an app, you can use the receiver.html code included with the sample. I'd been hoping you could just use the built-in OS X Apache server without all the fuss and bother. The sample is remarkably simple even if it is a bit hard to read. You start listening for a device. If one is found, you establish a media protocol message stream; that is, you begin talking to the device. You point the media content to a URL and set yourself to listen for updates. At any point, you can push request like pause and play to the device or listen for status updates from the device using a delegate protocol. You can learn more about Google's developer preview at the Google Cast site. Fun facts: Google Cast uses SSDP for device discovery. Details are in the GCKDevice.h header file. You receive notifications as device appear online or disappear. You can buy an inexpensive router if your Wi-Fi reception is iffy. This one is cheap and reasonably well reviewed. You should also be able to create a network if you have a Mac along with you.
DevJuice: Embed shell commands in an .app wrapper and other dev command line tricks
The other day, I was chatting with some Mac devs. One of them asked how to set up an App wrapper to run a custom shell script from the desktop. I use a script called appify created by Thomas Aylott and Mathias Bynens. It does little more than create the app bundle folder structure (top level.app/Contents/MacOS), copy the shell script, and then set its execute flag. As Aylott and Bynens discuss on a related blog post and its comments, other solutions like Wilfredo Sanchez's DropScript. (Sanchez also offers a sweet dmg building script at the same URL.) While I'm on the topic of my favorite command line solutions, I'd be remiss if I didn't mention lns, the best way to create symbolic links. It's perfect for drilling into Xcode folders. I always keep a link around to the top level of the latest SDK: lrwxr-xr-x 1 ericasadun staff 106 Jul 8 18:58 sdk@ -> /Applications/Xcode[REDACTED]-DP3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS[REDACTED].sdk and a second link to bring me right to UIKit headers. lrwxr-xr-x 1 ericasadun staff 71 Jul 8 18:58 headers@ -> /Users/ericasadun/sdk/System/Library/Frameworks/UIKit.framework/Headers By staging these as two items, I never have to update my headers symbolic link. I just modify the "sdk" one as new betas roll out. Another great dev symbolic link to have on hand takes you right to the simulator folder, so you can preload photos, access files, and so forth: lrwxr-xr-x 1 ericasadun staff 62 Nov 18 2012 sim@ -> /Users/ericasadun/Library/Application Support/iPhone Simulator Got some favorite dev-centric command line utilities? Drop a note in the comments.
DevJuice: HockeyCoach introduces crash report inspection and management
If you're a HockeyApp customer, the service that enables you to collect user feedback, distribute betas, and analyze tests, you'll be pleased to learn that the company has just introduced a new app. Just launched, HockeyCoach helps you view and manage your crash reports. With just a few clicks, you'll be able to view your source code side-by-side with the crash report. All you need is a git repository and a commit tag. Hockey Coach correlates the source with the symbolification to make sure you view the right error point. HockeyCoach also coordinates with bug tracker tickets. It's a free download for all current HockeyApp customers. HockeyApp plans start at $10/month for indies and go up to $300/month for Enterprise deployment.
DevJuice: Glyphish icon set updated for iOS 7
Glyphish, probably the most popular source for licensed iOS icons, has just been refreshed so you can get ready for iOS 7. Currently bundled at US$75 for Glyphish 3 through 6, this over-the-summer special saves you a cool 25 percent off the normal price. If you're already a Glyphish customer, it's the Glyphish 6 package ($25) you'll be most interested in. Using thin lines and inspired by iOS 7's visual style, these icons were designed using an Ive aesthetic. Here are a few examples that I pulled out of the packages to compare the old and new designs. Today, I was able to sit down with designer Joseph Wain to discuss the process of moving Glyphish to iOS 7, and hear his thoughts about the overall changes in the iOS design language. As you can see with these samples, Wain's evolved the entire look of the icon set. TUAW: So how did Glyphish 6 come about? Wain: I took my best guess about iOS 7 and where it's going. My goal was to support developers both in the near term, with resources for porting apps to iOS 7 and, fingers crossed, the long term as iOS 7 evolves. The launch-and-iterate approach will be the best approach to keep up with Apple's standards and matching their aesthetic over time. TUAW: The community response to iOS 7 has been kind of a mixed bag, hasn't it? Wain: I've heard a lot of short-term negativity and long-term positivity. I'm optimistic for the future of iOS 7 and I think the initial "shock" will wear off quickly. This is a good opportunity for independent developers to help Apple discover what an iOS 7 app will be. There's a lot of opportunity here to innovate both app design and UI design that you might not have had in iOS 6, because as an ecosystem it's so crowded. With iOS 7, independent developers can contribute back to what it means to be a good iOS 7 citizen. TUAW: What are the negatives about iOS 7 design? Wain: In terms of iconography, the iOS 7 look as a whole is very new, and very young. What we've seen so far in demos pretty clearly doesn't have the same polish as what we've seen before. Plus, the shock value is high because there's a big change, and designers like to nitpick -- they hone in on the details (And that's fine! They're naturally perfectionists!) but as somebody making icons, a lot of the iOS 7 icons are not something I would create. Some Apple icon choices look very strange on non-Retina displays. But how long will it be until Apple moves past Retina devices entirely? There are a couple of non-Retina devices right now. If you extrapolate out 18 months, it's not going to be a big problem any more. There's not going to be more non-Retina devices. There's more likely going to be zero. With Glyphish, I'm trying to see the forest through the trees. I'm anticipating Apple understanding that, so many of those issues will resolve. TUAW: What do you love about the iOS 7 aesthetic? Wain: From an icon standpoint, I love where they have successfully simplified the kinds of icons I make. In iOS 6, icons have been all over the map. Apple has followed the Human Interface Guide (HIG) just fine [but it's not consistent]. iOS 7 feels like a movement towards eventual resolution independence. Where things have been simplified successfully, it's been done very well. In terms of overall visuals, a lot of things may change between now and public release. If you want a joke, my joke with a wink is that I'm glad that iOS and Android finally look the same visually. The aesthetic of iOS 7 is more in the Android ballpark than previously. Things are starker and simpler if you subtract the motion and interactivity layer. As a designer, I like that I can see similarities in the visual style. I don't have to think of the rich skeumorphic world of iOS and the stark gray world of Android. TUAW: This all comes down to design languages, yes? Love it or hate it, iOS 7 seems more consistent as a design language. Wain: Not sure if I'd go so far. Everything I've seen in iOS 7 has come from Apple. We still have to wait for the entire app ecosystem to express it. Are Apple's iOS 7 apps consistent? Yes, maybe. We've moved past the rich Corinthian leather. But while the language still isn't consistent, it's certainly identifiable. It's certainly Apple. On other OS's platforms, designers have co-opted Apple's beautiful design language from the last five years. It's a karmic sense that Apple inspired elements are more identifiable as Apple. TUAW: Any changes in how the new icon set be used? For example, the plus sign is really thin. Wain: It will be different. I think in terms of UI components, developers will still use tab bars and tool bars and all, but there will differences. An icon may no longer work in the same role. Developers working now on iOS 7 will lead the way and hold the flag up high, and hold the torch for where this is going. In six months or so, this will all settle down and there will be a bunch of really great iOS 7 apps. TUAW: Thank you so much for your time! Readers interested in picking up a copy of Glyphish, whether the entire bundle or the individual Glyphish 6 update, can do so at the developer's website. The bundle offer is for a limited time.
DevJuice: Organize code snippets with Code Collector Pro
Code Collector Pro (on sale for US$9.99, normally $19.99) offers a snippet manager for your development needs. I bought myself a copy a few weeks ago, when it suddenly went on sale, and have spent the time since kicking its wheels. I was surprised to find out how much I like it. It offers excellent language-specific contextual highlighting, flexible tag support and easy-to-use searching. Whenever you have a snippet you want to store, just add a new item, paste and edit its metadata. I installed it into my Dock on day one, and it's been there ever since. I have not yet found a reason to close it, hide it or put it away. That's a big deal for me given how zealously I guard my permanent Dock items. Previously, I've tried using special-purpose Xcode projects, TextEdit files and even Notes to organize code bits. I was never really satisfied with any of those solutions. Code Collector Pro was built specifically for these kinds of short methods and functions that don't fit into class categories or helper libraries and it's doing a grand job in keeping those labeled, readable and (most importantly) findable. I really like the app and I suspect that you will too. There's a free 14-day trial available on the dev website and the app can be purchased at the Mac App Store.
DevJuice: Supporting the iPad 1
iOS adoption outpaces every other mobile family out there. As iMore reports, 93 percent of customers have upgraded to iOS 6.x. Just 1 percent remain on older operating systems. So why do developers obsess over iOS 5? The iPad 1. It's the little iOS that can. And does. And keeps doing. Devs continue selling apps targeted to the original iPad and they don't want to cut away an important portion of their market. I'm told over and over again, "If I go to Auto Layout, I can no longer build for iOS 5." A loyal base of iPad 1 users means developers hesitate to move their code base into modern technologies and that's a shame. Sadly, Apple doesn't allow devs to fork apps. Imagine freezing (but still selling) an iOS 5 version of your app. Consider a state of "no longer supported, but available to purchase" for a not-insignificant user base. True, 1 percent doesn't sound like a lot of users until you do the math. There are 600 million devices out there. That's 6 million potential customers. Now imagine this forking for iOS 6 as well come this fall. You'd be able to keep selling to those customers who haven't updated, but you wouldn't be slavishly adhering to outdated firmware that represents just a small minority of users. Sadly, this is not an option that Apple offers. Each update has the potential for excluding customers, something that gives devs hives. Fortunately, there's a way to suggest it. Developers shouldn't have to turn away from newer, better APIs because the alternative is their bottom line.
DevJuice: Recovering your UUID after upgrading
Some of our TUAW staff got really excited this week when the iPad beta of iOS 7 finally debuted. So excited, in fact, that they forgot to check if their device was properly registered with their dev account. They installed the beta -- and, as you probably guessed, got stuck. Fortunately, for those in such a situation, Apple provides an enterprise tool that enables you to retrieve UUIDs from unactivated devices. Website HighTechDad has a great post about exactly this situation. The iPhone Configuration Utility for Enterprise allows you to plug in your device and fetch all the information you need. So why not register directly through Xcode's organizer? The answer is that not everyone is familiar or comfortable in the IDE, especially those who play support roles on development teams -- such as designers, managers and others who aren't quite hands-on.
Dear Apple: Please reconsider button borders
Dear Apple, I'm somewhat disturbed about the interface changes you shared with us during the keynote and on your website. Specifically, I'm not especially happy about all those borderless buttons. Without affordances, those visual UI elements that suggest or reinforce areas of interaction, buttons have lost a critical user engagement piece. I'm certainly not the only developer who feels this way. You may assume that users are now long-since "trained" on iOS, that they will feel comfortable guessing where UI components are, and will "instinctively know" how to interact with them. I believe the borderless-button has gone one step too far. I don't believe that changing the color, as you would in an email message, is enough of a visual cue for many users -- especially those with borderline visual impairments who do not yet need assisted UIs. Please allow clear differentiation between buttons and labels to support discoverability, clarity and user deference, regardless of user training and background. To conclude, let me offer the following quote from the New York Times write-up of "The Guts of a New Machine": "Most people make the mistake of thinking design is what it looks like. People think it's this veneer -- that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works." - Steve Jobs Thank you for considering my bug report. Hat tip to Michael Heilemann.
DevJuice: iOS Artwork Extractor updated
Many devs find it useful to inspect system artwork -- whether for inspiration, for reverse engineering to help create consistent new elements or simply for curiosity. In that goal, there's been no better tool than the open-source iOS Artwork Extractor from Cédric Luthi. The project, formerly UIKit Artwork Extractor, has now been updated for pretty much any iOS version you throw at it, including iOS 7. It also now enables you to scan arbitrary frameworks, not just UIKit. It's a handy utility, one well worth checking out.
DevJuice: Launch image and app icon naming scheme
Some things aren't particularly obvious, but can be very handy to know for when you need them. With the hope that this will be useful to our DevJuice community, TUAW presents the following without further comment: LaunchImage-700@2x~iphone LaunchImage-700-568h@2x~iphone LaunchImage-700-Portrait~ipad LaunchImage-700-Portrait@2x~ipad LaunchImage-700-Landscape~ipad LaunchImage-700-Landscape@2x~ipad AppIcon72x72@2x AppIcon72x72 AppIcon60x60@2x AppIcon50x50@2x AppIcon50x50 AppIcon29x29@2x AppIcon29x29
Dev Juice: Parallels Desktop 8 update makes OS X Mavericks VMs, hosts possible
Just last week I was bemoaning the fact that neither Parallels nor VMWare Fusion provided an easy way for a developer to create a virtual machine (VM) for testing of OS X Mavericks, so I ended up installing the new Mac operating system on a separate partition. Today Parallels released an update to Parallels Desktop 8 for Mac that not only allows the update of existing OS X VMs to OS X Mavericks, but also allows Mavericks to be a host machine for Parallels. If there's a downside, it's that you still can't install OS X Mavericks on a blank VM; instead, you'll have to install a previous version of OS X on a virtual machine, then acquire the installer from the Apple Developer Center and upgrade the VM. The update can be applied to an existing install of Parallels Desktop 8 by launching the app and selecting Check for Updates under the Parallels Desktop menu. As of yet, there's still no word from VMWare on how they're progressing on OS X Mavericks compatibility, but we'll be sure to pass along any information that we hear about.
DevJuice: iOS/Android PortKit translates visual metaphors
The clever folk over at Kintek have posted a handy system-to-system guide for anyone working in the mobile development space. This metaphor overview quickly references how items like buttons, switches, one-of-n selection and other common interface items are expressed by default in the target arenas. You'll find items from Android, iOS 6 and iOS 7 listed side by side, so you can quickly review their visual presentation. Resource links take you to developer documentation. It's nicely done and well worth checking out. [Via Swiss Miss]
