Objective-C
Latest
Microsoft has iOS devs building the 'bridge' for Windows 10 apps
It's no secret -- even with its fast start, Microsoft needs more apps on Windows 10, across PCs, tablets and phones. Many of the most popular ones are already built for Android, iOS or even older versions of Windows, but supporting another platform can be tricky. To solve that problem, in April Microsoft announced "Windows Bridge" tools to make it easy for those developers to reuse already written code in new Windows apps. Now it's ready to live up to that promise, and is releasing an early look at the bridge for iOS today. More importantly, it's even opening up the source code (Github) for the Bridge tool itself so the people who will use it can help make it better. If you'd rather use apps than make them, then this doesn't necessarily mean you'll see ported over iPad or Android apps simply running on your PC, just that developers won't have to change so much of the stuff in the background to make them work.
Apple launches blog for new Swift programming language
With the release of iOS 8 getting closer by the day, Apple has started a new blog to answer questions about Swift, the new programming language for iOS and OS X. Swift aims to make writing code more interactive and fun, while keeping apps running fast. The opening topic for the blog addresses Swift's possible compatibility issues. Swift can work alongside Objective-C code, allowing developers to easily integrate it into their existing apps or build their own from scratch. As Swift evolves, Apple plans to provide Xcode tools to help move your old source code forward along with changes in the language. The goal with Swift is to keep your apps working now and into the future. From the blog: Simply put, if you write a Swift app today and submit it to the App Store this Fall when iOS 8 and OS X Yosemite are released, you can trust that your app will work well into the future. In fact, you can target back to OS X Mavericks oriOS 7 with that same app. This is possible because Xcode embeds a small Swift runtime library within your app's bundle. Because the library is embedded, your app uses a consistent version of Swift that runs on past, present, and future OS releases. You can check out the rest of the Swift blog here, including details about Binary Compatibility and Frameworks. For more information on Swift, head over to the language's announcement page.
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: 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: Stanford iTunes U course on iOS dev launches free textbook
If you're a fan of the highly popular Stanford iTunes U course on iOS development (CS193P), you'll be happy to learn that an official companion text is now available on iBooks. iPad and iPhone App Development covers the latest release of Xcode and the newest Objective C enhancements. Approximately 300 pages in length, this is an iPad-only (i.e., iBooks Author) text. The book supplements and updates the iTunes U videos for Xcode 4.5 and iOS 6. It is available in all 50 iBookstore countries. Best of all, it's free.
Makers of PaintCode open CodeAutomat service, for turning SVGs into code
I'm currently working on developing an iOS app in conjunction with a graphic designer, and because my design skills are pretty terrible, we set out to look for a solution to turn the scalable vector graphics (SVGs) he's designed into Objective-C code snippets I can insert directly in the app. There are a few different ways to do this, but it turns out that PaintCode (which Erica wrote about earlier this year) is the solution we're going with -- it's an app that will fairly easily convert scalable vector graphics into Objective-C code, which iOS can then use to draw out a user interface for a touch-based app. And it just so happens that just as I found their app, the folks behind PaintCode have released a brand new product. CodeAutomat is a new service, from the same developers, that's designed to make SVG-to-code conversion as easy as possible. All you need to do is upload your SVG file on the site (you can even drag and drop it in), and then for a small charge (starting at US$4.99), the browser-based app will turn your graphic into code, using PaintCode's formula. Now, PaintCode's price is $99.99 (on the Mac App Store now), so if you're converting a lot of graphics, you might want to splurge for the whole app. But the service is super easy to use, and works with any SVG file -- just plug it in and play. For those who need a few conversions but don't want to buy a whole app, CodeAutomat could be very helpful indeed.
Google releases new Java to iOS source code translator
Developers have their work cut out. Even if we (impolitely) sidestep the likes of Windows Phone, BlackBerry and the rest, those coders often have to pitch their work across web, iOS and Android. Google's trying to make that job a little easier, introducing a new tool that automatically converts Java source code into Objective-C, which is used in iPad and iPhone apps. While the J2ObjC tool can't tackle the UI for these, it does allow developers to craft other parts (including data access and nuts-and-bolts programming) into an easily shareable code without editing. Some existing Google projects already utilize the new translator, but its results remains a little temperamental -- the tool hasn't translated all possible paths just yet, and many Java devs have, according to the project page, "a slightly different way of using Java."
Facebook speaks out on the big app rebuild
We posted about the Facebook app update the other day, and if you haven't updated your app yet, you really should. The app is a prime example of why native development is almost always better than trying to do things with cross-platform web connections, and why it's so important, even for an online service like Facebook, to make sure an app performs well on a given platform. If you're interested in reading more about the process, Facebook has posted a substantial article over on its own Facebook page, walking through why this change was made and exactly how it was done. It's very interesting to read behind the technical scenes of how this update was created. The app essentially works in the same way that the previous version does, but it was built from the ground up in iOS' native Objective-C. The changes were all core to the process of running the app rather than UI developments, and if you have any development experience, it's wild to see the giant Facebook deal with the same issues that other iOS developers face. Of course, the drawback for all of this is that while the original HTML 5 app was relatively easy to update, this new app requires a little more code tweaking to change even basic things in the app. Facebook has done its best to build things as modular as possible (the new app even uses some of the code from the standalone Facebook Messenger app), but going forward, a more solid foundation may mean we have to wait longer for changes.
SSDs kick up performance for developers and users alike
I'm a developer. One of the things we devs do to pass the time is complain about how long it takes to compile and brag about the power of our development systems. Hot-rodding your system isn't just limited to development, though. There are lots of people out there who sit and wait as their systems limp along from the start up chime to the login screen. You probably already know that adding RAM generally makes your Mac more responsive, but do you know how much of a boost you might get from a solid-state drive (SSD) versus a conventional hard drive? TUAW friend Maurice Sharp decided to test it out. He got down and dirty with his Macs and timed how long it look for HDD and SDD based systems to perform various operations. Here are the results he achieved, comparing solid state response times to hard drive response times. 1 MacBook Pro 2.3GHz i7, 16GB RAM 2 Project build folders were cleaned before each compile 3 Build phase only. 2000 C++ and 400 Objective-C files 4 Mac Mini 2GHz i7, 8GB RAM 5 MacBook Pro 2.4GHz i7, 8GB RAM 6 MacBook Air 1.8GHz i7, 4GB RAM 7 21296 lines of code Look at the typical differences he experienced. Although this chart is focused on code-based tasks, his day-to-day startup times also massively decreased. Sharp writes, "There is one caveat. To switch over to SSD, you have to clone your current hard drive to the new drive. For a 500GB drive, this took about 4.5 hours (thanks Carbon Copy Cloner). Plus another 15 minutes to install the drive. Of course this can be done out of hours, or by an IT department if you have one. [But] now you can generate the numbers you need to show your boss, or even yourself, why an SSD drive is a good investment." Don't expect miracles, however. Another TUAW dev buddy Matthias Ringwald reports, "I replaced the HD in a 2009 Mac mini in 2010 with an Intel 160 GB SSD. While it got more snappy/faster boot times etc, the compile time for our Dybuster Dyslexia C++/Qt project decreased only from 7 minutes to 6 minutes." That said, a 17% decrease in compile time is nothing to sneer at. What's behind the difference? Sharp proposes "There are obvious things like the speed of accessing information on a the drive comparing a rotational system where the sector may or may not be at the head, and may or may not be cached, versus no reliance on mechanical rotation. But there are other things that may account for the lack of gain that Matthias was seeing. That is related to using the disk for virtual memory paging. "As you probably know, the OS uses part of the disk to swap out parts of RAM that are not in use, especially when the memory needed is greater than the physical RAM. If there is a lot of paging, that will suck performance, even with an SSD, as the system dedicates cycles to swapping RAM contents on and off disk. This is why I boosted my RAM first and got a sense of how that worked. Using something like iStat menus, you can see how much memory is being used and how it is allocated (as well as the processes that are hogging it!)" If you've gone to an SSD-equipped system on your development machine, has it made a dramatic difference? Or have the improvements been more subtle? Join in the conversation below.
Objective-C rocketing up the TIOBE charts
The TIOBE index is a chart of what have been rated as the most popular programming languages in the world, according to various searches online, the number of experts in those languages, and even software output (though it is very certainly not a strict chart of "most lines written"). Obviously, it can't be perfect, but it's at least a very simple indicator of what kinds of computer languages developers are using at any given moment. Look what has appeared at spot number 6: Good old Objective-C, the language that Mac and iOS developers use to code Mac and iOS apps. Mac and iOS development are gaining in popularity lately, thanks to both the Mac and iOS App Stores, and lots of developers are either jumping in to Objective-C development for the first time, or deciding to flex their coding muscles even more (often by leaping into the iOS fray). This chart shows just how phenomenally Objective-C is growing lately -- just since 2009, developers have started flocking to the platform in droves. That's pretty amazing. Part of it, of course, is that Apple has poured a lot of resources and development time into building up Objective-C and Xcode alike, but I don't think you can overestimate just how powerful the growth of the App Store as a distribution platform has been for Objective-C and its apps. [via DF]
Apple posts free developer documentation for iBooks users
If your resolutions for 2011 include teaching yourself to be a Mac or iOS developer, then Apple just gave you a very nice Christmas present. According to a tip from our old friend Nik Fletcher at Realmac Software, Apple has recently put a number of Apple Developer Publications books into the iBookstore for free. This makes it simple to grab these books, which range from "The Objective-C Programming Language" to "iOS Application Programming Guide," for reading on your iPhone, iPad or iPod touch. As our resident developer and iOS guru Erica Sadun points out, it's "kinda dumb" to have the books running on the device you're trying to develop for. It would be nice if Apple eventually made a version of iBooks available for Mac OS X. Although, as commenter Nick points out, once you have the books downloaded, you can open them with any app that supports the EPUB format, like Adobe's Digital Editions product. You can also get a Mac-compatible version of the books by going to the developer site and then selecting the PDF option to download them. The PDFs can also be used on the iPad or iPhone, but since Apple has done the work to convert these documents into nice EPUB-formatted iBooks, why not take advantage of their effort? By my count, there are six books available. To grab them, launch iBooks on your device, tap the Store button, tap the Search icon and then type in "apple developer publications." The books range in length from 44 to 200 pages, and they are great references to use with many of the other developer books from Pearson and Peachpit Press that can also be purchased in the iBookstore.
PhoneGap framework fine for App Store development, sez Apple
Now, we've all been concerned about recent updates to the iPhone dev agreement -- you haven't been sleeping and your parents are, quite frankly, worried for your sanity. And it's a heady subject: "what is the fate of PhoneGap in the wake of the iPhone OS 4 beta SDK?" Well, worry no more, little one -- it seems that Jesse Macfadyen, a contributor to the project, pinged Apple to make sure that users of the mobile development platform wouldn't find their apps rejected simply for using the tool. As you remember, the agreement states: "Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine" (and of course HTML and CSS are cool), so PhoneGap -- which indeed sticks to HTML, CSS and Javascript -- is totally safe. Now developers can get back to having their apps rejected for any number of other silly reasons. [Thanks, Bea]
Apple's iPhone lockdown: apps must be written in one of three languages, Adobe in the hurt locker
Apple's already got a veritable novella describing things you can't do with the iPhone as a developer -- create apps that execute their own code is the biggie, obviously, blocking technologies Flash and Java in the absence of a loophole -- but it seems they've locked down the ecosystem just a little further today with the release of the iPhone OS 4 beta SDK. Check out this snippet from the developer's agreement: Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). What does that mean, exactly? Well, it means that technologies like Adobe's iPhone compiler in Flash CS5 won't be allowed, simply because the source code of the app that you're writing isn't in a language Apple's comfortable with. The compiler had been seen as a potential boon for Flash devs that had already been blocked out of the iPhone ecosystem for lack of a true Flash player, but Apple's found a way to block even this workaround -- technically you don't need to be using Apple's own tools, but you've got be using one of three variants of a single programming language. It's hard to say why Apple cares, exactly, but we suspect that the company would have to analyze your app pretty closely to detect variances in how the compiler produced your machine code in order to determine that you'd violated the rule. This could be a blow to publishers -- Condé Nast included -- who'd been banking on Adobe Air to lead the digital push, since those guys presumably won't be able to bring their issues to the iPhone (and, more importantly, the iPad) without violating the terms of Apple's agreement. Protectionism is a core element of the iPhone's success, in Apple's view -- but ultimately, this might come out as a decision that's difficult to defend, unnecessarily sours publishers to the platform, and turns Flash devs' heads just a little grayer than they already were.
TUAW at Big Nerd Ranch: Aaron Hillegass
More coverage of TUAW's inside look at developer boot camp. See below for notes & disclaimer. On my last day at Big Nerd Ranch, I got a chance to sit down with with the biggest nerd at the ranch, Aaron Hillegass, and talk about nerds, NextStep, the iPad and more. Aaron has a unique vantage point on all things Apple, and it was definitely an enjoyable conversation. If you continue reading after the first video, there's a second short video of Aaron and I out at the site of the future Big Nerd Ranch.
TUAW at Big Nerd Ranch: now taking (app) requests!
More coverage of TUAW's inside look at developer boot camp. See below for notes & disclaimer. It's Wednesday at Big Nerd Ranch. I'll get to meet a few of the personalities behind the ranch today, as well as meet up with some blogger friends from Atlanta. Victor is even going to stop by ... it's like visitor's day, except without the rehab or prison part. We're well into learning to make use of the unique features of the iPhone SDK now. Yesterday we covered CoreLocation, the accelerometer, more Interface Builder and programmatically creating interface elements. I've done a little of this before, but I'm also learning solid memory management techniques, coding conventions and other areas that I definitely needed work on. My classmates are really starting to dig into their own projects, and I've put together a couple small ones of my own. I haven't come up with a great idea for a larger project yet, though, and I'd like your help with that. My only request is that it make use of at least one special hardware feature of the iPhone (compass, accelerometer, etc.). Beyond that, I'm just looking for unique ideas from our readers for an app that would be useful to as large an audience as possible. If this app makes it to the App Store, it will be given away for free, so leave me some suggestions in the comments and I'll get working on something we can all share! In order to give our readers the first-hand account of what it's like to experience developer boot camp, Big Nerd Ranch has permitted Brett to attend complimentary classes and has provided transportation/lodging assistance. Other than those considerations, no sponsorship or advertising relationship exists between BNR and TUAW. This series is not an endorsement of BNR's programs or teaching methodology.
TUAW at Big Nerd Ranch: cabin tour
More coverage of TUAW's inside look at developer boot camp. See below for notes & disclaimer. This is a quick video I shot on Sunday. It's a quick tour of my cabin, just to show you what the lodging and amenities at the Big Nerd Ranch look like. Participants don't spend a lot of time in their rooms, as the class schedule makes for a long day, and is usually followed by some lab time spent working on projects and getting answers to additional questions. Meals are served in the main building, so you end up spending a lot more time with the group than you do in cliques or on your own. The food, by the way, has exceeded my expectations, and the cooks have cheerfully catered to my dietary preferences (a picky pescatarian with a penchant for peanut butter and jelly sandwiches). Read on for the video of the cabin; I should have a video of the actual campus and some footage from our daily hike up soon, too! In order to give our readers the first-hand account of what it's like to experience developer boot camp, Big Nerd Ranch has permitted Brett to attend complimentary classes and has provided transportation/lodging assistance. Other than those considerations, no sponsorship or advertising relationship exists between BNR and TUAW. This series is not an endorsement of BNR's programs or teaching methodology.
TUAW at Big Nerd Ranch: meet Joe Conway
More coverage of TUAW's inside look at developer boot camp. See below for notes & disclaimer. It's Tuesday at Big Nerd Ranch, and we're deep into writing simple apps for our iPhones. Once Mark Fenoglio had finished teaching us some fundamentals of C and Objective-C, Joe Conway took over as instructor to lead us through actually creating iPhone apps. He'll be finishing out the course with us. Right now, we're studying CoreLocation, and creating maps on which we can find locations and add annotations. Things are starting to get interesting, and we're really starting to apply the knowledge to our own projects. The lab should be busy tonight! In the video after the break, you'll get a chance to "meet" Joe. I think the interview captured his Daniel Tosh mannerisms and humor pretty well (see the outtakes after the outtro). You'll see Joe at least one more time before the week is over. There will be some videos posted after the course, as we're actually in the middle of nowhere and the upstream connection isn't conducive to shipping large quantities of video to YouTube. That will be changing in the future, more on that when we talk to Aaron Hillegass. Continue reading for the video!
TUAW at Big Nerd Ranch: Mark Fenoglio
More coverage of TUAW's inside look at developer boot camp. See below for notes & disclaimer. I'm on my second day at Big Nerd Ranch, settling in and getting some blogging done between 3-hour lectures on Objective-C fundamentals. I sat down with our first instructor, Mark Fenoglio, last night to discuss Big Nerd Ranch from his point of view. He's a very dynamic guy, even if my "talking head" video angle doesn't portray that very well. If you're curious about the kind of people Big Nerd Ranch has on the teaching staff, this is a good introduction. I've also got a few clips of classmate "first impressions," some walking tour-video of the ranch and plenty to write today, so you'll hear more from me soon. To view the video, click on the "Read more" link below. In order to give our readers the first-hand account of what it's like to experience developer boot camp, Big Nerd Ranch has permitted Brett to attend complimentary classes and has provided transportation/lodging assistance. Other than those considerations, no sponsorship or advertising relationship exists between BNR and TUAW. This series is not an endorsement of BNR's programs or teaching methodology.
Cycript: Blending Objective-C and JavaScript
Cycrypt is a new project that blends Objective-C and JavaScript to make it easier to implement aspects of both together. It's going to be great for using elements that JavaScript offers when programming with Objective-C. It's similar to JSCocoa, but it's been designed to offer a more complete set of JavaScript commands. It offers a full JavaScript parser/serializer, which allows for extensive use of JavaScript coding. If you're wondering what exactly this is, the Cycript page offers some examples of code written with Cycript. Basically, it allows you to implement full JavaScript commands, while working with Objective-C in the same project. Cycript is dependent on the MobileSubstrate and libffi libraries, which are available in Cydia. This won't be used to develop applications in the App Store anytime soon. If you're interested, you can download examples or releases of Cycript. It's still being worked on, but if you're developing with both Objective-C and JavaScript in a project, you should check it out.
Is the future of Mac...the iPhone?
I was chatting with my TUAW colleagues this morning about Mac versus iPhone programming. And as per usual with these conversations, we veered in the direction of unfettered speculation. It's an occupational hazard. As someone who regularly develops on both platforms, I declared that the iPhone represents the future of Mac programming. The iPhone, I posited stated, offers a great new platform without the need to be fully backwards compatible like the Mac. Our own Victor Agreda challenged me to back up that position. After a bit of time and thought, I decided to do so in this post. My key point is this: Apple's engineers have learned a lot of important design lessons during the history of OS X. When the iPhone debuted, it gave those engineers the chance to rebuild an OS and an API from the ground up. Those engineers could craft a platform and its libraries that built on the Mac's successes without dragging along its less fortunate design decisions. Yes, there were some lemon frameworks that initially made the grade, but over time, Apple has reduced their number. Even now, Apple continues its iPhone design process, adding new frameworks and APIs at a prodigious rate. The iPhone OS remains a work in progress, developing in ways and directions that the initial release two years ago could not have anticipated. And Apple does this, knowing fully that the closed platform allows them a great deal of design freedom that would not have been possible on the open Macintosh. In contrast, consider in how many ways the Mac's successful history drags the platform down. A commitment to existing APIs and historical design practices show up in nearly every Mac development project. The simple elegance of the iPhone's built-from-the-start-as-Objective-C 2.0-based API is largely missing from Cocoa libraries. Whether you're working with buttons, menus or simple text views, the iPhone development approach simply works better: beautiful 2.0-style properties, consistent API design, better-thought-out object inheritance trees, and so forth. With the iPhone, you see a great new platform evolving without the need to be fully backwards compatible Snow Leopard, with its minimal API changes has bought the Macintosh a few years of stability. But I think it's time for Apple to rethink the platform as a whole, re-imagining its API through the lens of current iPhone OS development. While Snow Leopard offers Apple the room to stay still for now, I can see Apple moving forward in a separate engineering effort to Cocoa Touch Mac, a hypothetical cross-platform OS that supports general development on iPhone and future Mac devices like my imaginary snow-princess-rainbow-pony-iTablet. The ghost of NeXT-past, as TUAW-colleague Joachim Bean puts it, still haunts us. It's time to exorcise the unhelpful bits of that pervasive spirit and usher in the new age of the iPhone and its API design examples. Mac OS X is, and has been, a superb development platform. What I'm suggesting is that iPhone OS might just be a better one.
