DevJuice
Latest
DevJuice: The easy way to set up an OS X Mavericks test environment
OK, this is going to be a "duh" moment for most Mac developers, but apparently there are some people who are having issues with setting up a test environment in which to run OS X Mavericks. I have to admit that I was one of those who first started asking if anyone was having success running the latest Mac OS in a virtual machine under VMWare or Parallels. There are some people who claim to have OS X Mavericks running fine under one virtual environment or the other, although most are being rather closed-mouth about how they accomplished it. So, tired of waiting, I decided to do what I've done with previous releases and just create a dual-boot machine. It's stupid easy to do this: 1) On your OS X 10.8 machine, sign into your Mac Dev Center account, click on the appropriate tab for OS X Mavericks, and then download the OS X 10.9 Developer Preview (click the button, which launches the Mac App Store, and magic happens). 2) While you're waiting for the download to complete, it's time to set up your Mavericks partition. Fire up Disk Utility, click on your primary disk drive and add a partition. I made mine 64 GB (on a 256 GB SSD MacBook Pro with Retina display), named it Mavericks just so I'd be more apt to select it instead of my main drive when installing 10.9, and then let Disk Utility do its thing. This takes very little time, so go enjoy the outdoors while the download continues and try to get some sun. 3) Once the Installer has finished downloading, it should launch itself; if not, go into Applications, find the app named "Install OS X 10.9 Developer Preview" and launch it. Follow the instructions, select the Mavericks partition you created in step 2 as the target for the beta OS and sit back while the installation continues. 4) Now you have a dual-boot 10.8 / 10.9 machine. To boot into one or the other of the partitions, just hold down the Option key while rebooting and select the appropriate one. Of course, that's not particularly helpful if you just have a single development machine and you don't want the irritation of booting in and out of two versions of OS X several times a day. That's why as soon as things are working smoothly with Parallels 8 and/or VMWare, we'll pass along the instructions for setting up Mavericks virtual machines in both of those environments.
DevJuice: Is your app watching you?
The PRISM project is hitting the news just now, with the Director of National Intelligence issuing statements, and people talking about what privacy means in a free society. This morning, our backchannel discussion about PRISM drifted to the topic of user privacy in apps. Specifically, we've noticed a recent trend -- our apps are starting to contact us by email. Here's an example of a real email generated by an iOS app: Hello, Thank you for trying [redacted] out! I noticed that you've used the app a couple of times over the past few weeks but are no longer using it. We trying to make the calendar a better experience and in doing so I'd really appreciate if you could take a moment and tell me why [redacted] isn't working for you. If you have any other thoughts you'd like to share with the team, please feel free to send it our way! That's a pretty startling email to receive, especially when we never contacted the company in question or opted into monitoring. In fact, the app in question offers a lengthly privacy statement, which states, "we may use other Anonymous Information to analyze usage patterns". Clearly that data is not so anonymous that it wasn't able to hijack the Gmail credentials used within the app. There's a saying that basically goes, "if the app is free, then you are the product." It's become commonplace to reap device and usage statistics for analytics. Developers may forget that there remains a real privacy line between a user's personal data and how they use the app. With Apple's support of developer- and app-specific tracking identifiers, you shouldn't lose sight of how that data is supposed to be used. In February, the FTC issued recommendations for mobile privacy disclosure. Among these, the FTC suggested that apps offer affirmative express consent for access to sensitive information, along with an access "dashboard" that would allow users to review in-app privacy settings. At the time, Verne Kopytoff wrote at Bloomberg Businessweek about the motivation behind app privacy policies, "Privacy advocates like to call mobile phones by a more menacing name: tracking devices. Mobile apps log the pages people browse, the products they buy, and the videos they watch. Many apps also note their users' locations and, over time, glean their daily routines." As mild as email feedback outreach efforts are, they cross a critical line when leveraging account information meant for in-app use only. A user who buys an app intending to manage his calendar, isn't expressly trying to build a product feedback relationship with the developer. Repurposing Gmail account credentials for further contact breaks an important trust.
DevJuice: Reveal enables you to inspect, modify and debug iOS apps
Reveal, now in public beta, was originally created to enable its developers to debug client applications. Over time, they found that the tool became so useful on its own that it deserved to be productized. Developer Sean Woodhouse tells TUAW, "We built Reveal to help us debug applications for our clients. The applications we build, particularly for iPad, can have extremely complicated view structures, and Reveal's ability to isolate and focus on a subset of the view hierarchy has been critical to manage that complexity. The ability to change view properties also lets us test simple visual changes without recompiling." If you're thinking that Reveal sounds a lot like Spark Inspector, which I recently wrote about, you're right. Reveal covers much of the same ground in terms of application inspection, tweaking and exploration. It does so, however, with its own flair and interface strengths. I am very impressed by this product. The app provides a handy "tl;dr" jumpstart for anyone testing it out. Choose Help > Integration Guide. All you need to do to get started is link in a few frameworks, set a build flag and run your app in the simulator. Reveal automatically detects and integrates with any app running its custom framework. Even better, the app stores that framework in its own bundle, so there's no other material to incorporate. From the app download to up and running, it took me maybe a minute to get going. Once running, select your running app. You can tweak items in the View inspector (the third of the four inspector panes) and your changes are automatically injected into the application. You can see the simulator update live. For the app I was testing, I messed around with frames and content modes, and found the app to perfectly adjust those items. Elements in the other three panes appeared to be inspect-only in my testing. Reveal is not targeted at Auto Layout at this time, and some of my tweaks put Auto Layout's nose out of joint a bit, such as when I attempted to set a view's affine transform to non-rectangular results. This app will be best for anyone still working in the frames and bounds world, who wants to be able to adjust their interfaces in real time. It's perfect for developers who prefer not to rely entirely on Interface Builder and who use extensively use code. With Reveal, you'll be able to update interfaces without endlessly performing the tweak-build-test cycle. Instead, you explore in a live playground until you've found the interface you're looking for. Like Spark Inspector, I would have liked to have had a product output of some kind, whether it was PaintCode-like code generation, bookmarks of saved interfaces (for later review and comparison) or just settings charts. Unfortunately, neither product offers these options at this time. I'd also love if Reveal integrated with constraints. I almost never deal directly with frames and bounds any more now that Auto Layout has debuted, and I think I would find a tool that let me create, inspect and validate those rules a lot more valuable. That said, Reveal is a lovely app even if it's one I wish I had had about two years ago before Auto Layout premiered. Its interface is top-notch, it's easy to use and I really enjoyed exploring it. Because it's in open beta, I highly recommend that you download a copy and poke around. You may discover that it's exactly the dev tool you've been missing.
DevJuice: 10.8.4 and the iOS Simulator
TUAW reader Peter Johnson of Soluble Apps writes, "I, and a few other developers on my Facebook group, have noticed that, since yesterday's OSX update, every other run on the simulator is crashing on start. It appears to work fine when compiling and running on hardware. I thought it could be useful for your to warn other developers to hold off from performing the update if they want to work on the simulator." I've experienced the same issue, but found that switching from LLDB to GDB (on the advice of Tony Arnold from Apple's Dev Forums) seems to fix the problem for the moment. Update your scheme by selecting Product > Scheme > Edit Scheme, and choose the GDB debugger for your debug scheme. Update: Apple says no more radars are needed. The issue occurs to a process race condition for debugserver. Instead of using GDB, you can alternatively kill your execution, wait a few seconds for the app to wrap up, and then run the next iteration.
DevJuice: A real-world lesson in why you must test on-device
Dave Caolo's daughter has been working hard on a school report regarding the Everglades National Park. So he downloaded a nice-looking iPad app on the subject for her. Swiping around it looked great. And then he tapped on a video. This is what happened. In the TUAW back channel, we scratched our heads, trying to brainstorm any reason for an app to directly link to a YouTube video that didn't support mobile. The best we could come up with was this: we figure that the developer never tested the video on an actual iOS device. But then we tested this theory by trying out the video URL on the iPhone simulator. It didn't work there either. So probably the developer never tested the video at all. That said, although the simulator looks like an iPhone, it never provides a perfect representation of the physical and computation abilities of device deployment. Sometimes, it may reflect a Mac reality over an iOS one. So if you specifically provide a video as part of your app, you should really make sure that it plays back within that app, and not just on the simulator. We'd also recommend that you control the rights and distribution of any material that's fundamental and essential to the app in question. That addresses the problem of another video used within the app. It said: "YouTube account associated with this video has been terminated due to copyright violations." Oh, excellent.
DevJuice: Forage offers SQLite query GUI for devs
The OS X Forage (US$9.99) app provides a simple query and editing interface for SQLite databases. This app targets developers who use pre-built databases for iOS, OS X and Web deployment. It enables them to test and refine queries as well as to edit table data, and do so outside of the command line. It's a pretty sweet little app. I was able to open, edit and save updates to a variety of database files. Admittedly, my testing was fairly light, but it easily handled address book and photo databases from the iPhone, which are my primary area of testing, as well as several test databases provided by the developer. Updates are handled as transactions. You can add and change data but the changes aren't stored until you specifically hit the Save Changes button (you see it at the bottom of the table editor, next to the row add and delete buttons). Visual updates (they're subtle -- you may have to change your selection to see them) indicate which items have been changed. You cannot yet revert without saving, but that's something promised for future releases. You create new SQL queries by double-clicking on tables. Each query occupies a tab in your workspace. In the following screen shot I have two query tabs in process. These tabs enable you to tweak each SQL query independently. You cannot, at this time, name the queries, but it's pretty easy to move through the workspace as needed. Yes, the app is in early days, and the only big complaint I have is that the app itself isn't fully stable. I managed to crash it a number of times. The developer assures me that a bug fix update is imminent and will address the problem. For now, what you're buying is an evolving product that shows promise, and one that many developers will find useful even now.
DevJuice: Spark Inspector offers real time iOS interface inpection
Spark Inspector (US$39.99 single-license) offers an exciting new development tool. Targeting devs looking to refine their user interfaces, it enables you to interactively tweak view properties like frames and layers. The app centers around an Interface Builder-like experience, with familiar-looking attribute and size inspectors. If you're comfortable in Xcode 4, you'll easily find your way around this tool. In addition, it provides a custom layer inspector -- one that could (and, honestly should) inspire Apple. It enables you to update layer attributes like shadows and transforms, while viewing the results in real time. Perfect for devs who otherwise write their interfaces in code (I am guilty as charged), it breaks out of the tweak-build-run loop that takes up so much time and energy in the normal development day. Instead, you apply your tweaks within the app itself, adjusting the interface until it looks just right. This is the point at which Spark Inspector displays its one big weakness (keep in mind that it's still in development). Instead of producing an updated XIB (which would be okay) or PaintCode-like Objective-C output suitable for re-integration to your apps (which would kick ass), you take responsibility for transferring values back to your Xcode project. Honestly, It's not a huge deal -- especially when your tweaks change a constant from say 50 to 58.5 -- but it's something that could be a killer feature in future updates. For now, you make notes of what values worked best for you. And no, there's no "bookmark this UI for later comparison" option either, another thing I would have liked to have seen. One of Spark Inspector's nicest features is its 3D extrusion display. This pushes views out in parent-child hierarchies, letting you explore and select items with more tangible visualization than you get in IB. Spark Inspector also offers a notification inspector, which may be useful for some devs. If you're already writing your UIs from code, however, you probably know how to set up a listener that logs notifications. Setup is easy. There's a setup assistant for configuring Xcode projects, or (if you're paranoid like I am) add both the SparkInspector and libz frameworks to your dev builds, making sure to enable the -ObjC flag in Other Linker Flags. Include the SparkInspector header as such: and enable the inspector in your application delegate, typically in application:didFinishLaunchingWithOptions: Make sure you test using the simulator, and not (as I first tried) on device. The standalone Spark Inspector app (DMG) must be running. As soon as your app hits the "enable observation" stage, it seamlessly connects to the inspector, and you're ready to test and tweak. For forty bucks, this promises to be a valuable tool that many devs will benefit from. If you'd like to kick the tires before you buy, there's a free 30 day trial available on the Spark Inspector website. If you do decide to buy, you purchase directly from the vendor.
DevJuice: Apple's ObjC-JavaScript Bridge
In a new post at his Steamclock Software blog, Nigel Brooke writes how Apple has added new Objective-C-to-Javascript bridging to WebKit: "This new API supports straightforward embedding of the JavaScriptCore interpreter into native Objective-C projects, including reading and writing variables and object members with appropriate type coercion, calling methods on JavaScript objects, and directly binding Objective-C objects into JavaScript." The API performs its bridging using Objective-C protocols, enabling you to bind JavaScript calls to Objective-C implementations. If you'd like to give the tech a test, Brooke has posted a working sample project at github. Hat tip iOS Dev Weekly
DevJuice: Does WWDC need a lottery system?
WWDC sold out in just minutes this year. As iOS developer Josh Avant put it, "Next year, tickets are going to sell out before they even go on sale." Many developers were greeted by server errors, failed purchases and the "Sorry, tickets are sold out" banner. Others, like Daniel Jalkut of Red Sweater Software, were able to place an order. In the end Jalkut decided to cancel his ticket, stating, he was "[v]ery conflicted, but it ended up feeling too exclusive for me." In a move that was seen as a boost to fairness, developers were given a day's warning about sale time. This enabled people around the globe to set their alarms and schedule their visit to Apple's developer site. Unfortunately, the high demand for the "golden" tickets meant that distribution was both chaotic and random. The overloaded system presented bugs, as reported by various parties on Twitter. "I never once got anything but an error page," said developer David Green. "Apple seriously needs to change how they handle WWDC tickets, that went beyond unfair and into untenable." "It timed out on me when I submitted the purchase," agreed developer Scott Yelich. So why not switch to a less intense lottery system? Sure, the results are still random, but distributing purchase requests over a week or month surely would avoid the technology-based limits created by so much demand at a single moment (not to mention sleepless nights caused by time zone differentials). Did you snag a ticket? Or were your attempts unsuccessful? Drop a note in the comments and share your story. Think WWDC needs fixing? Here are TUAW's proposals from last year.
DevJuice: Better Objective-C associated objects
iOS/OS X internals guru Gwynne Raskind tipped me off to a much better way of creating associated object keys. Until now, I've been doing this: static const char nametag_key; return objc_getAssociatedObject(self, (void *) &nametag_key); Turns out there's a much easier and better way. That's because Apple's selector implementation uses a fixed address. That means you can declare a property, for example: @property (nonatomic) NSString *nametag; and then use that property's selector as the key: return objc_getAssociatedObject(self, @selector(nametag)); It's way cleaner, requires no extra static variables, and according to Gwynne, "It's absolutely safe and rather cutely self-documenting in current runtimes -- and for the foreseeable near future, no question." Could this eventually break? Gwynne tells me that Apple would probably have to implement a completely new ABI for that to happen.
DevJuice: Three useful Xcode tricks
Some Xcode challenges seem to crop up repeatedly. Today, I thought I'd share a few solutions that you might find helpful to integrate into your workflow. Challenge: When you move an Xcode project to a new folder, all your file references die. Solution: Avoid those red "can't find" file references by changing the way each group defines its location. If you're pulling in a suite of code from another folder, select it and open the File inspector (View > Utilities > Show File Inspector). Choose "Absolute Path" from the Path pop-up. Now, when you move the folder, those files remain fixed to the original location. You won't "lose" them in the update. Challenge: Your project is jam-packed with groups and subgroups and you want to find a file in your project. Solution: Start with File > Open Quickly (Command-Shift-O). Enter enough text to locate the file name you're looking for. Once you find the right name, for example "BezierFunctions.m", select the name and click Open. The file now appears in the workspace editor. Right-click within the editor and choose Reveal in Project Navigator from the contextual pop-up. Presto, Xcode finds that file for you, opens its parent group or groups, enabling you to manage the file and within its group setting. Challenge: You're using a function or type and want to quickly reference the original declaration. Solution: Move your mouse to the item in-code, and Command-click. Xcode immediately jumps to the original definition file. Alternatively, press the Option key. The cursor switches to "?" and a dashed highlight appears under the item name. Click to reveal a pop-up menu. Choices on this menu vary, depending on whether the selected item is custom or system supplied. In this screenshot's example, you can click on BaseGeometry.h to open the file that declared the POINT_IS_NULL macro, providing an equivalent result to command-clicking. The option-click trick also offers more info in addition to the move-to-declaration option, particularly for system-supplied items. Yes, you can jump directly to the CGPath.h header file using this little trick, but you can also read a description summary or hop to the class reference document.
DevJuice: Provisioning portal redesigned, allows deletion of some App IDs
We've been hearing from various delighted developers this weekend responding to Apple's redesigned provisioning portal. And yes, you can now delete many (not all) App IDs from the portal. The newer the ID, the more likely it seems to be that you'll be able to select it, configure its settings and click that all-too-welcome delete button. Did it work for you? Drop a note in the comments. Me? I've been happily weeding many apps out this weekend.
DevJuice: WebCode premieres, generates JavaScript+Canvas
As I've been working on a new book on iOS Quartz Drawing, I've been using PixelCut's PaintCode app pretty heavily. Today, a new PixelCut tool just hit the Mac App Store. WebCode (US$49.99) generates JavaScript+Canvas, CSS+HTML or SVG code on your behalf. If you've used PaintCode, WebCode will feel immediately familiar. Similar tools and same panes make the new app very much like the original. Instead of generating Objective C, however, you're presented with ready-to use Web source. The app just debuted, so I have only played with it a little bit. WebCode, I should note, supports Photoshop PSD import as part of its base features -- no in-app purchase needed.
DevJuice: Preview of Fasten dev utility
Today, I got a peek at a little utility that converts iTunes URLs to more readable App Store versions. From developer Moshe Berman, Fasten automates the process Apple described in QA 1633. I found the app easy to use and a great timesaver. Berman tells me that it's in the review queue as I write, but he's still deciding on the price. For a buck or two, it's a handy thing to have around. It does one thing, but that one thing is pretty useful.
DevJuice: Apple will no longer accept apps that use UDID calls starting May 1
Apple has posted a warning on their developer news site that they will no longer accept apps that reference the unique device identifier, starting May 1. It writes, "Starting May 1, the App Store will no longer accept new apps or app updates that access UDIDs. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6." This move follows almost a year after Apple began enforcing the initial deprecation. In related news, Apple will no longer accept pre-Retina apps starting on May 1. All App Store apps must be built to support iOS devices with Retina displays as well as the iPhone 4" family.
DevJuice: Beginning Objective-C
Jim Dovey and Ash Furrow just released Beginning Objective-C. It is subtitled "Get started with programming the fast-growing language." It is not, however, really aimed at new programmers. Unlike Aaron Hillegass's superb Objective C Programming: The Big Nerd Ranch Guide, the book expects a reader who's an experienced programmer, even if that reader is new to iOS development. Beginning Objective-C's chapters are already discussing interface bindings by page 11. Language fundamentals (such as conditionality and loops) start at the end of page 16 and wrap on page 22. At least half the book focuses on non-language topics such as networking and data management. In fact, here's the TOC for you to review. Chapter 1: Getting Started with Objective-C Chapter 2: Object-Oriented Programming Chapter 3: Foundational APIs Chapter 4: Objective-C Language Features Chapter 5: Using the Filesystem Chapter 6: Networking: Connections, Data, and the Cloud Chapter 7: User Interfaces: The Application Kit Chapter 8: Data Management with Core Data Chapter 9: Writing an Application Chapter 10: Après Code: Distributing Your Application Beginning Objective-C retails for US$39.99, but you can pick up a copy from Amazon for about $27. The Kindle edition is under $20.
DevJuice: PaintCode offers new Photoshop import IAP
See the bunny in the screenshot to the right? It started life as a Photoshop shape. As you see it there in the simulator, it's now a UIBezierPath. It got there courtesy of PaintCode. I first reviewed PaintCode last year. It offers a high-end resolution-independent design tool for transforming vector graphics into Objective-C code. In its latest incarnation, you can now import Photoshop files. The new feature is a US$19.99 in-app purchase on top of the $99.99 app, but if you'd like a sneak preview, you can download the demo version from the PaintCode website. The demo version is quite limited; you cannot copy code or use the app for more than 20 minutes at a time. I personally think this is a killer feature. It greatly simplifies the way many people already have a workflow, integrating Photoshop directly into the coding process. Plus, for design idiots like myself, you can purchase shape libraries for Photoshop and then use those vector graphics in your apps. (I would, however, suggest carefully reading through any license agreements to ensure that what rights you think you're buying are actually the ones you do purchase.) In addition to plain shapes, PaintCode will also import layer effects like gradients, color overlays, shadows and patterns. This means you can design a complete button in Photoshop and draw it into your app using Objective-C code. The new upgrade is available now. Choose Store > In-App Purchase Store to get started. Existing PaintCode owners will be happy to learn that version 1.3 of the app introduces new features in addition to the paid Photoshop upgrade. You can now import SVG, enabling you to import drawings from Adobe Illustrator directly to PaintCode. PaintCode also now integrates images into your drawings, plus it's added groups so you can combine many shapes to a single, more manageable object. Update: TUAW reader Dave Anderson was kind enough to send over a vector DogCow so I could test the new SVG import added in version 1.3. It worked great. Thanks, Dave!
DevJuice: Sneaking a peek at Bill Van Hecke's upcoming book
If the name William Van Hecke doesn't ring a bell, he's the User Experience Lead for The Omni Group. He's the guy behind those beautiful interfaces, or as he puts it, "I try to make Omni Group software look presentable and behave politely." When my editor at Pearson said I could get a sneak peak at his Learning iOS Design manuscript, I jumped at the opportunity. I've heard Bill speak several times at conferences, and am a big fan of his practical design approach. Learning iOS Design is basically design porn for developers. It offers chapter after chapter of advice, tips and explanations. From a tour of system-supplied classes to the essence of visual and functional simplicity, this book provides an in-depth dive of app design and the user experience. My favorite of the chapters I was able to preview were Chapters 8 and 9, "The Graceful Interface" and "The Gracious Interface," which describe how apps accommodate user tasks in both beautiful and user-centered ways. Other chapters discussed the design tension between richness and plainness, goal-centered design (with a big section on removing features that distract from an app's focus), prototyping and developing cross platform. After my initial taste of this book, I can't wait to read it in its final form. You can preview the table of contents here and a pre-order page is already live. The book should ship in June.
DevJuice: Spellchecking short strings
A few years ago, xkcd created a crowd-sourced color survey to collected real-world hue descriptions. You'll find the hilarious results here. I've been working on updating my UIColor utilities as part of building a color-sampling app. Stumbling across this survey, I decided to add the xkcd colors to my repository, along with code that matched colors to their nearest xkcd equivalents. What I found is that as delightful as the sourced color descriptions are, that they were rather full of misspellings, for example "urple." So I put together a simple NSString category to find misspellings and "creatively" described colors. I found this approach to be useful enough that I decided to share it on a DevJuice. Normally, you use text checkers to find misspellings in text view and fields, and to present those items to the user. But you're certainly not limited to that scenario. This simple string category lets you test whether a misspelled word was found, enabling me to automate my inspection. I loaded up the xkcd names as an array and searched them to find any potential errors. Out of nearly a thousand color names, it quickly flagged about two dozen issues -- saving a huge amount of detail checking. This doesn't of course, guarantee the correctness of my results. I know I left in a few amusing misspellings: "Blurple," for example, plus if any misspellings ended up as a legal English word, they will not have been flagged. What's more, I had to bowdlerize some entries. Apple does not have any "offensive language" tester that I could find. (Know of one? Please ping me about it!) So I had to update those items by hand. In any case, I hope you'll find this useful. Happy coding!
DevJuice: Apple exception snarks
Life is hard for Apple engineers. Long work hours, high demands and little exposure for individual achievement. That's why it constantly amuses devs to find little bits of humanity interspersed among their development tools. Incept Development's Dimitar Ivanov sent in an email today regarding an exception he encountered. He writes, "Someone at Apple must have been quite irritated when writing exception strings." Here's the exception in question: [23877:907] *** -[__NSCFCalendar components:fromDate(): date cannot be nil I mean really, what do you think that operation is supposed to mean with a nil date? An exception has been avoided for now. A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil. I did a little searching through the CoreFoundation frameworks and confirmed these strings for a variety of errors (components, from dates, to dates, etc.), as well as a few other cute messages like: *** ERROR: this process has called an NSArray-taking method, such as initWithArray:, and passed in an NSSet object. This is being worked-around for now, but will soon cause you grief. For the record, my very favorite internal string comes from the MobileDevice framework: This is not the droid you're looking for (is actually %@). Move along, move along.
