ObjectiveC
Latest
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.
Xcode 3.2 Daily Tip: Adding actions and outlets in IB
More Xcode daily tips for Mac and iPhone developers. Back in the old times, when dinosaurs roamed the earth (and used less sophisticated IDEs), Interface Builder offered a built-in class browser as part of the project window. This browser allowed to you navigate through the Objective-C class hierarchy, and add subclasses along with instance variables and methods. You could generate files from those classes as a skeleton for further development. Then for a while, the class browser went away. And it was missed. But it is back again. New to Xcode 3.2, the Interface Builder Library pane hosts an updated class browser. This new subpane combines features that have recently been in the Class Identity Inspector (namely, adding outlets and actions to a class) with the ability to generate new subclasses from existing classes. So how does it work? I may be a brontosaurus but I prefer the old style browser to the new style "Lineage" display shown here. The new pane is certainly pretty, and it fits in well with the Library pane concept of collecting elements that are universally used throughout a project, but it lacks a certain ease-of-browsing that the old tree-style presentation used to give. All aesthetic and usability concerns aside, it's important to know that the Outlets/Actions interface has moved from its prior home into a new one. The interaction objects remain essentially unchanged. Use the + button to add outlets and actions, the - button to delete them. Double-click the default types to change them to a different class. You can locate a class by entering a string into the search field at the bottom of the pane. The pop-down action menu on the bottom-left offers a number of class-related functions including subclassing, displaying group banners in the class list, writing out updated class files, and more.
AppLoop brings automated application development to the iPhone
With the iPhone SDK, Apple is pioneering a new mobile development platform that is ahead of it's time; however, this innovation comes with a major caveat: It requires Cocoa (or Objective-C) programming knowledge. You may ask "Why is this a problem?" Well, someone might have a really great idea for an iPhone application, but not have the programming knowledge to back it up and follow through with the idea. This is where AppLoop comes in.AppLoop is a brand-new service that allows anyone with a web browser and RSS feed to create an application similar to the AP News app and submit it to the App Store -- without ever writing a single line of code. Their service works by generating a .plist file on the server side (based on your choices). The file is then passed through a couple of AppleScripts that generates the code based on the choices, and compiles it. The entire app-creation process takes less than a minute to complete, and you have an application ready to be deployed to the App Store. Ad-hoc versions can be requested in advance of the app being placed on the App Store. Currently, AppLoop is offering the RSS reader application, but they have plans to add additional paid features down the road.You can find out more information about this service by visiting their website, or by watching the video [link here] above. You can also see a gallery of screenshots from one of their applications.%Gallery-34925%Thanks for the information, Eric!
In which, iPhone apps are built
It turns out that creating new GUI iPhone apps is both harder and easier than you expect. Saturday night when the first iPhone UI app proof-of-concept appeared, I was tied up with family. I frantically emailed Mike Rose begging him to get a post out, which, wonderful man that he is, he did. Sunday, I grabbed what time I could, intent on testing out the new developer toolchain produced by Nightwatch and company. In summary: if you can wait for an already-compiled binary toolchain to emerge, do so. The developers have done all they can to make building the tools as simple a process as possible. The folks on the irc.osx86.hu #iphone-uikit channel are helpful and supportive. But the bottom line is pre-alpha means pre-alpha. There many rough compiling patches along the way where I ended up hitting my head against the wall, convinced I could never get the tools built. I had to edit the source several times to get it to compile on my Intel Mac Mini.
