xcode
Latest
Xcode 4 Preview 2 available for download
Have I mentioned how much I adore Xcode 4? I would marry it, bear its children and clean up after it -- that's how much I love it. But Xcode 4 hasn't been readily available for general use. Until now. As of this evening, you can download Xcode 4 Preview 2 and throw yourself into its exuberant yum. At least you can if you're a member of one of the paid developer programs. Yes, all that Xcode 4 goodness is now yours to enjoy, whether you went to WWDC or not. So point your browser over to Apple's developer site, log in with your Mac or iPhone paid developer credentials, and download yourself a big hot steaming pile of IDE yum. It's like the chocolate lava volcano cake of development tools. Thanks, Luke Rhodes
Rumor for developers, developers, developers! Steve Ballmer to present at WWDC?
Barron's reports, you decide: According to Trip Chowdry, an analyst with Global Equities Research, Microsoft CEO Steve Ballmer will have seven minutes of stage time at WWDC 2010. [Wait, what now? –Ed.] According to Chowdry, Ballmer's topic will be Visual Studio 2010, Microsoft's development suite.The supposed announcement will center on VS10's hypothetical ability to write native apps for iPhone, iPad, and (gasp) Mac OS. Currently, such apps can only be created in Apple's Xcode environment. There are a couple of schools of thought that might discredit or support this rumor. On one hand, the current Xcode-only development regime requires a Mac. As many of us know, once you go Mac, it's difficult to go back; these iPhone and iPad developers may go on to make great Mac apps, too. The flip side of this is that requiring Xcode, and thus a Mac, serves as a large barrier to entry for many developers and the apps that they could potentially make. VisualStudio may attract users who wouldn't switch desktop platforms to develop for the iPhone or iPad. Given the notoriously secretive nature of Steve Jobs's keynotes, it's difficult to imagine that information like this, if true, could slip out. It's also hard to reconcile the full-court press against other IDEs for the iPhone (the notorious 3.3.1 clause) with the idea of letting Microsoft deliver a fully supported development platform for Apple's crown jewel devices. [Translation: Trip Chowdry may have some bad intel here. –Ed.] WWDC will begin on June 7, 2010. [via MacRumors]
devsugar: A better way to share ad-hoc builds
Hey, Dave Howell. This post is for you. Dave's company Avatron is in the midst of a beta program for its newest application, Air Display. Steve Sande took a first look at Air Display not too long ago, and I've been messing with it too. The thing is this: Avatron is still sending out zipped application files and separate mobile provisions. As I told Dave, there's a much easier and better way to do Ad Hoc under the 3.2 and later Gold Master iPhone OS SDK. Ad Hoc provides a way to distribute signed, secure applications outside of App Store channels. With Ad Hoc, you can send your applications to up to 100 registered devices and run those applications using a special kind of mobile provision that allows the applications to execute under the iPhone's FairPlay restrictions. Ad Hoc distribution is especially useful for beta testing and for submitting review applications to news sites and magazines.
Use mailsend to send email from the Terminal
Update: After this article was written I learned of mstmp which I highly recommend instead of mailsend. There are times that I want my iMac to be able to email me: when certain scripts run via cron or launchd, when certain events happen (a backup has been completed), etc. I've found that none of the included command-line programs work. The good news is that, with a UNIX foundation, it was fairly easy to find a free program which would do just that. A little searching turned up a free program called mailsend, which will work. For this example I will be using a Gmail account, which requires OpenSSL. Your mail server may not require OpenSSL support, but if it's possible, I encourage you to use it. The short version of the instructions are as follows: 1) Download and install OpenSSL to /usr/local/ssl/ 2) Download and install mailsend to somewhere in your path such as /usr/local/bin/ 3) Use mailsend -h to learn how to use it on the commandline 4) (Optional) Use TextExpander 3 to fill in some of the variable fields, such as To, Subject, and Message. Read on for more of a step by step walk-through.
Steve Jobs responds on iPhone SDK's new Section 3.3.1
The release of the iPhone 4.0 SDK to developers included, in the accompanying agreement, Apple's new mandate that apps must be written in C/C++/Objective-C. This seems to block the use of alternative development environments for iPhone apps, such as the upcoming Flash CS5. As criticism of this condition has mounted, we now have Steve Jobs responding to an e-mail from Tao Effect's Greg Slepak on the topic, sparking a discussion between the two on the change. Jobs pointed out John Gruber's recent analysis of the change, calling it "insightful and not negative" as compared to the knee-jerk reaction in the first few hours after the SDK agreement surfaced. The revised viewpoint suggests that the real reasons behind the move are to maintain innovation and quality as more and more apps are written for Apple's touch platforms; meanwhile, we've also heard a somewhat plausible technical explanation-slash-rationalization for the move. After Slepak read the piece, he responded in turn: "I still think it undermines Apple. You didn't need this clause to get to where you are now with the iPhone's market share, adding it just makes people lose respect for you and run for the hills.... From a developer's point of view, you're limiting creativity itself. Gruber is wrong, there are plenty of [applications] written using cross-platform frameworks that are amazing, that he himself has praised. Mozilla's Firefox just being one of them." Jobs wrote back, "We've been there before, and intermediate layers between the platform and the developer ultimately produces [sic] sub-standard apps and hinders the progress of the platform." Slepak replied again to clarify his position, and there's no further word from Steve -- yet. This from Jobs, and the echoing statement that's in Gruber's article, both largely ignore the fact that plenty (most?) of the 85 million users buying and running applications on the Touch OS (whether on iPhone, iPod touch, or iPad) don't care how those apps are created as long as the app experience is compelling -- they wouldn't know an IDE from an SDK, or be able to tell Xcode from Flash on a bet. As fellow TUAW staffer Mike Rose points out, in the case of Unity, "that platform is enabling game development that would simply not be taking place otherwise on the iPhone." Right now it's not clear whether Unity is on the good or the bad side of Apple's new rules, but if the philosophical argument against third-party tools holds water, there are lots of apps already on the store that may be in trouble. Assuming that users 'wouldn't like' apps made with those third-party tools, and that Apple is therefore justified in protecting the platform from crappy apps, strikes us as more than a bit paternalistic -- especially after the onslaught of fart apps and the recent Bikinigate, it's hard to accept "Apple knows best!" with a completely straight face. [Via MacRumors]
iPhone OS 4.0 dev agreement blocks using Flash or Unity as IDEs?
UPDATE: We've heard directly from Unity Technologies themselves, and the company's CEO, David Helgason, has been in contact with Apple over the matter. Helgason says that so far Unity has "no indication from Apple that things are going to change." This is consistent with John Gruber's viewpoint on the new iPhone OS 4.0 dev agreement. Gruber originally thought that Unity3D would be a prime candidate for banning under the new rules, but given that Unity3D is, in Gruber's words, "a pre-processor than a cross-compiler," it's nowhere near as certain that Unity will fall on what Gruber calls "the wrong side of the line" per the new dev agreement. Gruber's opinion on the fate of Flash CS5's iPhone compiler under the new rules is... we'll say, "somewhat less rosy," and given the already strained relationship between Apple and Adobe, he's very likely correct. Daring Fireball's John Gruber has found an interesting potential "gotcha" in the newest developer agreement for iPhone OS 4.0. In a section titled "PIs and Functionality," there's a sub-section written in a way that could spell the end for translation tools like Flash Professional CS5's Packager for iPhone or Unity Technologies' Unity iPhone Pro. The relevant clause starts out by saying, "Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs." That's nothing new, and has already been the basis of many App Store rejections. But it goes on to say that apps "must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine." This could be interpreted in many ways, if not for the clarification that follows: "Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited." Adobe's Packager for iPhone is a tool that basically "translates" Flash games into iPhone-compatible versions using ActionScript 3. Unity iPhone Pro similarly allows game code to be outputted into Xcode, and from there it's a very short trip to submitting an app to the App Store. Although the code these two tools output is fully iPhone-compatible (it would have to be, or it would never get approval), the new developer agreement could easily be interpreted as saying, "iPhone apps have to be developed from the ground up in Apple's development environment, or we'll reject them." If true, developers who have depended on tools like Packager for iPhone or Unity are, perhaps justifiably, going to be very displeased that their IDEs are no longer supported. It's easy to see why Apple would make a move like this -- having "ported" apps in the App Store opens the door to bug-riddled apps with potential security holes -- but it's also easy to sympathize with those who would cast such a move as only one more example of Apple's iron-fisted approach to software development on their mobile platforms. Disclaimer: I am not even remotely close to being a developer, so it's entirely possible that I'm misinterpreting all of this. If I'm off-base and there are any devs out there who'd like to set me straight, let us know in the comments.
SDK devsugar: Re-signing applications
TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature. A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity. A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions. #! /bin/bash export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate codesign -f -s "iPhone Developer" $1 There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated. Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it. You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign. Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time. Please note the following caveats: I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application). When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail. This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here. To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.
Gamesalad offers $99 iPhone game publishing
We mentioned Gamesalad's plans to bring their publishing system to the iPhone earlier this year, and now they've done it: for $99 a year, they say that you'll be able to design games on their game creator development tool, and then publish them straight out to the iPhone's App Store. If you don't want to bother publishing the games yourself, you can create them and have them "viewed" through the Gamesalad Viewer (which we couldn't find on the App Store quite yet), or you can export them out as full applications and publish them as your own iPhone apps (Flutterby is in the store right now as an example of a Gamesalad Creator game). There's also a $1999 membership service that lets you customize every aspect of your games, and provides you with direct customer support, which is supposed to be for "elite users" (like, we guess, actual game companies). And truthfully, I've developed a few apps using just Xcode, and it's not too big a deal (though I've never had to go through an actual release or worked with end users, which I'm sure is most of the battle anyway). But if the thought of using professional coding tools to develop your little game idea sends you into panic attacks, and the Gamesalad creator seems more your speed, this might be a nice viable way for you to turn your gaming idea into App Store gold. It costs nothing to download and try out the creator, so if the idea interests you, you can work on putting a game together, and then pay later when you decide you've got something you want published on the iPhone. And hey, if you do put a game up, be sure to send a tip and let us know -- we'd love to see the end products of this process.
Xcode Tip: Updating your documentation
It appears that the Dev Center at Apple just updated its documentation set today. If you're using Xcode 3.2 and you want to update your documentation, you might be looking in the wrong place. Before 3.2, you used to update your documentation in the Developer Documentation window (Help > Developer Documentation, or Command-Option-?). Now you'll find your documentation sets in the Xcode Preferences window (Xcode > Preferences... or Command-, and then choose the Documentation tab). Also, if checked, Xcode will automatically update your documentation when you launch it. This Documentation panel offers subscription options for installing a documentation set (such as, for example, Mac OS X Legacy Library or iPhone OS 2.2 Library) as well as a handy Check and Install Now button that lets you request the latest updates. Use this to keep on top of the latest documentation updates. Thanks, Scott Lawrence and @zadr
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.
Xcode 3.2 Daily Tip: Analyzing Your Code
More Xcode 3.2 tips for Mac and iPhone developers. The LLVM/Clang static analyzer bundled with the Snow Leopard developer tools automatically detects a variety of memory management bugs in Objective-C programs. It's a terrific tool for finding memory leaks and other issues and it is now easily available to all developers, both for the Macintosh and iPhone platforms. I first learned about using the analyzer with iPhone projects from a blog post by Joe Heck of rhonabwy.com. Heck pointed out that the Intel-only analyzer worked with the Intel-based Simulator code generated by the iPhone SDK, letting you use the analyzer with your iPhone projects. At that time, you had to download a copy of the analyzer, install it by hand, and run it from the command line. It was amazingly helpful but a bit of a pain to use. No more. Xcode 3.2 incorporates the static analyzer tool directly into its IDE. Choose Build > Build and Analyze (Command-Shift-A) and the analyzer automatically checks your code. and presents any bugs detected by the analyzer. Static analysis evaluates source code to automatically find bugs, issuing hints that are similar in nature to compiler warnings but targeted at Foundation (Cocoa) and Core Foundation memory management. Each bug is marked with a blue icon and a description. I do wish that the text didn't seem to "cut off" so abruptly. Resizing the Xcode editor window does not affect the hard right alignment of the bug reports. This bug refers to the local watcher variable, which is allocated and initialized but not released. The tool is not perfect. It may flag nonexistent "bugs" in programs, so there are definitely false positive results that will show up as well as gray areas. In this example, the watcher is used until the application teardown, so the fact that it's leaking is not really a problem. That having been said, the analysis is amazingly helpful and if you do find real bugs, the Clang Static Analyzer team solicits bug reports. To learn more about your bug, click the blue branch icon in the code itself. The analyzer offers a detailed view of the bug and its issues. This presentation provides more information about the specifics of the issue at hand. In this detail view, clicking any single blue arrow opens the Build Results pane, showing the analyzer result list. Hide or show analyzer information by clicking the blue branch icon in the left gutter. It's easy to overlook the new built-in static analysis feature of Xcode 3.2, but you'd be missing out on a great feature if you didn't explore it further.
Xcode 3.2 Daily Tip: Restoring Monaco
It's a Menlo world in the new Snow Leopard Xcode. 10.6's Xcode uses the Menlo Regular-11 font for the standard Xcode template. If you miss Monaco (and I know I did), it isn't hard to restore the look and feel of Xcode 10.5's defaults. That's not to say there's anything wrong with Menlo. Menlo is a lovely font. It's just not a familar font and some strange part of my brain keeps freaking out every time I look at the screen. I'll probably force myself to adapt to Menlo at some point but for the moment, I'd rather just stick with Monaco. So to do that, here are some quick instructions. As you'll see you'll need to create a new theme based on the Xcode default theme and update its font settings. To start, open Xcode > Xcode Preferences (Command-,). Choose Fonts & Colors. Select the Xcode Default theme and click Duplicate. Enter a name for the new theme (e.g. Normal Xcode Theme) and click OK. Select the new theme, and then select all categories within the theme. To do that, click on any item and then choose Edit > Select All (Command-A). With the categories all selected, double-click in the font column. A font panel appears. Select Monaco 10 in the font panel and then close the panel. Click OK in the preferences pane and boom. You have returned to a font comfort zone. Got any Xcode font preferences? Can you recommend a font that's better than Menlo, Monaco, or the good old standby Courier? Let us know in the comments.
Xcode 3.2 Daily Tip: Upgrading Xcode
For those about to code, we salute you. Developers: are you ready to upgrade your new Snow Leopard install to Xcode 3.2? The Xcode installer package appears in your Snow Leopard disc's Optional Installs folder. Double-click the mpkg file to open the installer and begin the installation process. Xcode 3.2 offers a number of really great new features, several of which will be highlighted in upcoming daily tips. Standouts include the new built-in static code analysis, the two new LLVM compiler front ends (GCC 4.2 and Clang), and the new Build Results window. Until you install, you may run into problems using the standard C compiler from the command line. (It threw errors about not finding <stdio.h>, etc.) This despite the fact that I had already re-installed the iPhone SDK. Once I upgraded to the new Xcode, and rebooted, the command line cc started working again. The reboot step seemed necessary because cc didn't work until I did so. There might have been a less extreme alternative I'm not aware of to use instead. (If you know of one, please let me know in the comments!) You'll need to re-install your iPhone SDK packages as well. Make sure you download the SDK versions that were built specifically for Snow Leopard. The iPhone Dev Center provides both Leopard and Snow Leopard SDKs for each of its standard and beta distributions. Install these packages after upgrading to Xcode 3.2. I did not and ran into trouble with project creation (as well as the already mentioned command line cc) until I finally got the install order corrected. Update: Remember, the iPhone SDK packages do not include Xcode 3.2, so just downloading the iPhone SDK for Snow Leopard will not upgrade Xcode. Thanks go to hatfinch for his help.
Dev Corner: Signing iPhone apps for informal distribution
At times, iPhone developers might like to test out applications without going through the formality (or challenges) of ad hoc distribution. Ad hoc distribution was introduced by Apple to allow software testing on up to 100 registered devices. It is, admittedly, a bit of a pain. Developers must collect device information (the "UDID", aka their unique device identifiers), register that device at the iPhone developer portal, create an special provisioning certificate, add a special entitlement, and build an ad-hoc only version of their software to distribute along with that certificate. If all that seems like a hassle, well, yes it is. It is, however, the proper, authorized, and recommended way to distribute pre-release software, whether for testing or reviews. But there is another way. If you know for sure that your target audience is another developer, the process becomes way easier. You can simply compile a normal development build of your application and send a copy of that build to another developer. That's because each registered developer has the ability to sign applications. Although the app was built to work with just the in-house devices you've registered for development, another developer can re-sign that application using the simple command-line script shown here. #! /bin/bash export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform\/Developer/usr/bin/codesign_allocate codesign -f -s "iPhone Developer" $1.app This script uses Xcode's codesign utility to sign the already compiled version of the application. Once applied, you can then install the application through Xcode. So is this a general distribution solution? No. And thank heavens for that; free trading of app binaries would rapidly lead to piracy. This approach allows developer-to-developer testing and collaboration only. The development signing is limited to the units you have personally registered. If you want to try this out, follow the link at the start of this post. It leads to a testing folder I keep around and occasionally stock with software that I need tested. It also includes a copy of the script, which you must make executable (chmod 755 signit).
The iPhone is a platform for coding newbies
I love hearing this about the iPhone: the San Francisco Chronicle has a piece about how Apple's little revolutionary telephone has brought a whole new crop of programmers into the development mix. People who had never before looked at code or considered writing their own applications are getting ideas about how to make better software, picking up Cocoa and Xcode books, and going to town. And strangely, we might actually have fart apps to thank for this -- people aren't just seeing the iPhone as an innovative platform, but they're seeing the App Store as an "anything goes" environment, where even their silly little idea might work. I don't know if we can pin all the credit for the burgeoning iPhone development scene on fart apps and the impression that even a monkey can make bestselling iPhone software (certainly Apple has set the bar and price for entry pretty low, both with the extremely cheap $100 fee for a developer account as well as the high quality Xcode software that comes on every Mac), but there is definitely something in this little device that's driving people to try and create their own software for it. Oh, and the money probably helps, too. Still, whether people are taking up iPhone development because they want to make millions or are just looking for another hobby, it's us, app consumers, who will benefit.
iPhone Dev 101: The "Hello World!" app
In the last iPhone Dev 101 post, I told you a little about creating your first project using Xcode; however, in this post, I want to show you how to create your first application that will run in the iPhone simulator. In honor of staying with the classic way of teaching programming, we'll create a "Hello World!" application as our first one. Creating the new projectIf you have installed the iPhone SDK/Xcode, then you can launch Xcode by navigating to /Developer/Applications. Once there, you can double click on the Xcode application (you may also find it handy to just drag the icon to the dock if you will be using it a lot). Once Xcode launches, click File > New Project. Under the iPhone OS section on the left side of the resulting window, select "Application." Select "View-based Application" from the templates that show up on the right side, and then click the "Choose" button. You will then be prompted to specify a project save name -- this will also be the name of your resulting application, so choose your project name wisely. You're project has now been created, and the Xcode window that is displayed will contain all of your code, resources, etc. There isn't much there now, but the application is fully functional at this point. You can click the "Build & Go" button in the toolbar, and the application will be compiled and launched in the iPhone Simulator. Again, this is a fully functional application, but it doesn't do anything useful at this point -- the usefulness of the app is up to your coding, but Apple supplies you with the base code and dependencies.
iPhone Dev 101: Creating Xcode projects, brief Xcode UI overview
In our last iPhone Dev 101, a continuing series on iPhone development, we talked about resources that you can use while you are coding with Cocoa. In this dev post, I'm going to walk you through Xcode and creating your first project.First we need to open Xcode, so once you have the SDK installed, you'll need to open /Developer/Applications/ and look for Xcode.app. This is Apple's IDE (Integrated Development Environment) that allows you to code, debug, test, and build all of your iPhone and Mac applications. When you open this application, nothing specially really happens, although you might see the welcome center -- if you see this, you can choose to disable it at startup by using the check box at the bottom. To create a new project, select File > New Project. In the resulting window select iPhone OS Application > View-based Application, and click "Choose." You will then need to specify a save name and location for the resulting files that will combine to create your application. In the resulting Xcode window, you should note that most of the work is already done for you!At this point you have a fully functional application. Try it out: click the "build and go" button at the top of the window and wait while the app is compiled and opens in the iPhone Simulator. The app definitely doesn't do much, but still, it's a running application you made without writing any code. Continue reading to learn more about Xcode, and get a brief UI overview.
Rolando's Simon Oliver in the Daily Mail
The Daily Mail has reported the story of our friend Simon Oliver, creator of Rolando (whom we interviewed quite a while ago when the game originally came out). Apparently things have worked out very well for him -- the game has sold 700,000 copies so far, Oliver's set to be a millionaire, and he's now, as he says, the head of a game studio that already has a hit under its belt. Very impressive (too bad they still call him a geek).It's stories like this that are pushing the little App Store bubble we've got going nowadays -- every investor with money to spare (not as many as usual, given the current economy) is happy to sink it into releases for the iPhone, and while there is plenty of money being made, not every developer ends up like Oliver (let's not forget he had a quality product in the first place).But there is some good news here: without the App Store and the iPhone platform, this never would have happened. Say what you want about Apple's release policies or their initial "no SDK" choice, but with the iPhone, they've brought development and distribution down to anyone who can dream it.
Cocotron: bringing Cocoa to Windows
Cocotron is a potentially exciting open-source project that "aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.'s Cocoa documentation." What this means is that, in principle, Cocotron would allow an OS X Cocoa app written in Xcode to be easily cross-compiled for other OSes, particularly Windows.Of course that in principle still leaves open a bunch of practical difficulties. The guys over at Magnetism Studio (developer of FileMagnet for iPhone) have a great account of how they used Cocotron to port their Mac FileMagnet Uploader to Windows. Of course it wasn't as easy as pressing a button and having a Windows executable pop out of Xcode, but after suitable adjustments (particularly to get rid of Mac-specific code) it did make a Windows version possible. In any case, Cocotron seems poised to make cross-platform development a much less costly and time-consuming process for Mac developers.Cocotron itself is a free download and released under the MIT license.[via Daring Fireball]
Apple Tutorial: Developing with MacRuby
Apple has posted an interesting new tutorial on developing OS X applications with MacRuby. MacRuby is an implementation of the Ruby programming language "ported to run directly on top of Mac OS X core technologies such as the Objective-C common runtime and garbage collector, and the CoreFoundation framework."What this means is that applications written with MacRuby can be a full-fledged Cocoa application with all the advantages that entails. The tutorial will take you through the process of installing MacRuby as well as building a sample application with Xcode. So if you've ever wanted to get started thinking about developing for the Mac, but have always been intimidated by Objective-C (which pretty much describes me), playing around with MacRuby might be just the ticket to get you started. [via MacVolPlace]
