Cocoa Zombies – NSZombie

Found this great little debugging tip over at MarkJ.net. The short of it: You can use NSZombie tracking to debug memory crashes in your code. Great find – this whole time I was kinda under the impression that there was a lot of educated guessing involved based on where your fingers last touched code. I’m so naïve.

Compiling PHP5.3.x on Snow Leopard

I like to wait quite a while before upgrading Mac OS X to the newest release because, for me, it often requires quite a bit of work. I had hopes that Snow Leopard would be different because Apple finally installed current versions of the whole LAMP stack, but I wanted to wait regardless… just in case.

Why the wait?

I do dev work that require custom libraries in my PHP installation – vanilla PHP from Apple doesn’t have what I need. To do that I’ve relied pretty heavily on the Fink package manager. Too many times I’ve upgraded to the new OS and some of the libraries haven’t yet been updated to work properly on the new system. Usually after a couple months either the libraries get fixed or Google will give me enough results and clues that I can fix the issue myself.

First things first

I went ahead and compiled  Apache from scratch. It’s easy enough and you’ll need the 64bit support for PHP. MySQL was much easier – download the intel x86_64 installer for Mac OS X 10.5 (yes, even for Snow Leopard). Side note – MySQL finally got around to recompiling the System Prefs Pane to 64bit.

Installing Fink

I’ll save you some time. First, compile fink from source. When you set up the app, do the 64bit-only packages (you’ll know – it’ll prompt you to pick 32bit or 64bit). I tried the 64bit and PHP wouldn’t install. You can always do a separate mixed architecture install later (see here for details on mixed fink arch installs).

Compiling PHP (with GD)

I need GD. This tutorial did the trick – once I had figured out the 64bit fink issue(s). Follow it and the companion standard PHP / Snow Leopard compile tutorial, linked in that article. Take a look at my compile flags, if you’re interested:
export MACOSX_DEPLOYMENT_TARGET=10.6 \
CFLAGS="-arch x86_64" \
CXXFLAGS="-arch x86_64"


./configure --prefix=/Library/PHP5 \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--sysconfdir=/etc \
--with-config-file-path=/etc/php.ini \
--with-zlib \
--with-zlib-dir=/usr \
--with-openssl \
--enable-zip \
--enable-exif \
--enable-ftp \
--enable-mbstring \
--enable-mbregex \
--enable-soap \
--enable-sockets \
--with-curl \
--with-curlwrappers \
--disable-cgi \
--with-iconv=/sw \
--with-gd \
--with-jpeg-dir=/usr/local/lib \
--with-png-dir=/usr/X11R6 \
--with-freetype-dir=/usr/X11R6 \
--with-xpm-dir=/usr/X11R6 \
--with-apxs2=/Library/Apache2/bin/apxs \
--with-mysql=/usr/local/mysql \
--with-mysqli=/usr/local/mysql/bin/mysql_config \
--with-pdo-mysql=/usr/local/mysql

Two things: First, my PHP is installed into /Library/PHP5/. Second, my Apache is located at /Library/Apache2/. Nothin to it. Too bad it took me all day to figure this out. At least now I can move on with my life!

Trends and Trajectory

As 2009 comes to a close I’m sitting in a nice, comfy coffee shop, working on some code for an iPhone app I wanted to release a couple weeks ago. I’m not going to be hard on myself. The Holiday season came upon us and there became more important things like family, friends, and feasts. This evening I’ve spent some time reflecting on my journeys over the last 12 months and begin figuring out where 2010 might take me.

I’ve pretty much immersed myself in mobile development the last couple months as some exciting new projects have hit the desk. It’s changed my view of computing. I don’t think much is new, but the added perspective is certainly important. For the sake of pointing them out, something needs to be said about the tremendous growth in a few trends – the ones that will continue explosive growth well into the future.

Web

It’s no surprise that SaaS (software as a service / “pay for play”) has made it pretty big, especially with companies like 37Signals leading the way in team collaboration. Tons of companies are copying the business plan because it can work tremendously well. SaaS is quite a game changer over the old boxed software model. The ubiquity of the net makes it easy for customers to connect to a service, do what they need to do, and leave without ever thinking about all the dirty parts of actually maintaining a computer. There are tons of other great benefits to SaaS, but I’ll just have to save it for later.

UI

It’s no surprise that we’re finally arriving at the Renaissance of user interface design. Tools and information have become improved enough that instead of spending a ton of time writing code, and more time designing appealing interfaces. We see this in both desktop apps and the web.

Platforms

Mobile is big. It’s not going away. This is not about that. Apple’s iPhone has revolutionized our concept of the application development model. It has shown us how apps that do one or two things, but do them well, have taken the place of monolithic apps that try to do everything, but only sort-of well. I don’t think the iPhone can actually take credit for this, but it is probably among the largest driving factors in this mentality shift . We also see similar shifts in online tools (37Signals with their collaboration suite) and desktop apps (Compare the beautiful Billings.app from MarketCircle to Intuit’s Quicken and Quickbooks).

Beyond

I never promised anything revolutionary, but when you look at the horizon it’s pretty clear to see where the current trends will continue to expand into meaningful user experiences.

Case in Point: Orbital iPhone App

Check out this article in TUAW about how an iPhone app, Orbital, isn’t really making it for the developer after less than (nearly?) 100,000 units sold. The article suggests it’s just a case of bad luck. True? I’m not so sure. Here’s why.

Saturation

It seems to me that the App Store is pretty saturated. To clarify – the iPhone App market feels pretty saturated. I don’t mean that good apps don’t come along from time to time, however the sheer volume is daunting. I searched the App Store for “Camera” and came up with about 1200 matching apps.

Marketing

Face it, you can’t rely solely on the App Store to do all your marketing. Get into the top lists and you’re got a pretty good shot of doing well your first couple days. If you don’t, good luck with getting potential customers to find your app out of the thousands that accompany it in the store. It’s time to get involved with good ol-fashioned marketing – just like every other product in this world. Pretty soon developing profitable iPhone apps looks a lot like developing the boxed apps, but without the boxes and retail chain.

I think I’m done blogging about this for a while. Nothing like beating a dead horse.

Take a Moment and Take a Survey

Take a moment to take this survey at A List Apart. As a web professional, it’s a worthy cause.

Thoughts for the App Store

With regards to last night’s post on App Store pricing itself into an unprofitable wasteland, I thought of something.

What if there were two versions of the App Store? One for inexpensive, useless, or just plain bad apps, and another for apps that met certain price, quality, or other criteria?

For those wishing to make iPhone development their business, the current version of the App Store isn’t the ideal marketplace. Finding apps can be challenging – either your searches aren’t quite coming up with what you’re looking for, or you have to wade through pages and pages of apps that don’t interest you. The other problem is the pricing competition with people who may not have similar economic goals as you do.

App Couture

Apple could offer different development tiers. Break the App Store down into groups indicative of where developers enroll. Keep the $99 price point for individuals. After that, add one or two more tiers for the ambitious or the corporate developers – maybe at $499 and $999. I don’t think Apple needs to add additional features. The benefit from joining the higher tiers is that you get placed in the App Store Premium. It’s App Store Couture. Could you also maintain a category for ad-free apps? Never mind the small advertising on the info/about page. I’m talking about those annoying little pop-ups at the bottom of your screen.

With those benefits are going to be some pitfalls. Just because somebody pays several hundred dollars for the premium listing does not ensure a quality product. And what with the fees you pay, will Apple do with it? It’s not up to me, but if it were – how about using some of that extra cash to improve the approval process?

App Graveyards

Let’s take this another route -  take old apps behind the barn, à la Old Yeller. Ok – maybe a bit extreme. Why not make an app graveyard where old apps go to die. By placing certain requirements on how often apps must be updated, Apple could, in theory, keep the App store fresh by keeping new and newly updated apps, while throwing the abandoned ones to the App Store Graveyard. In all likelihood you’re probably not interested in using many of the apps first developed when the iPhone was released. It’s not too big a task for developers to make small, incremental changes on a regular basis. It’s a sticky place to be in. On one hand you’ve spent a lot of time (money) on developing an application, and now you have to spend more refreshing it every so often. The updates might not drive new sales – money wasted, so to speak. Could that problem be solved by simply having to re-submit apps once a year? Uncertain. Surely it would produce some undue burden on the app approval team for apps they’ve already approved before.

Indies

Who wouldn’t like Apple to open up the distribution channels to third parties? I could see this open the possibility for independent virtual storefronts where retailers have the ability to pick and choose the apps they feature through their store. This approach has two possibilities that I think could work. First – Apple could open the iTunes AppStore to an affiliate program: App Store Indies. Online retailers could list apps on their website, but the whole thing link back to iTunes, as it does now. The second scenario would be the ability to distribute apps outside of iTunes, but still retain that special Apple-certified seal of approval that is required already. The apps, registered and digitally signed through Apple, could be available for download, or even boxed up and sold in block-and-mortar stores. There would have to be an economic incentive to Apple and the retailers to make this work. Because Apple owns the only distribution channel, I don’t see any reason why they would want to change unless it meant more dollars for them. That could easily be achieved through higher-priced premium apps. As a consumer, I like the idea of multiple outlets because I come to know and trust certain retailers and go back to them repeatedly. The cream will rise to the top – those retailers selling good apps will succeed, but at least they have the incentive to not bend to the price wars.

Am I biased? You betcha. As a developer, I want to make sure that I can make a living out of what I do. I can’t afford to spend hundreds of hours on projects for the chance of making one or two thousand dollars, 99¢ at a time. The App Store may have become a popularity game, but that doesn’t mean it should do so at the cost of making a living – especially if the iPhone platform is going to continue to be a profitable platform for the developers. If the money leaves, so will they.

Race to the Bottom: iPhone App Store Pricing

I’ve had a notion for some time that the price wars on the app store may be detrimental to the community. I know I’m not alone in this feeling, and have found others online who would agree. Finding like-minded developers isn’t my goal. I’m wondering when, or if, the App Store will begin to resemble something a little closer to desktop boxed software prices.

I think it would be wrong to assume that mobile apps will reach the cost of boxed software. However, I do believe we’re shooting ourselves in our proverbial feet by pricing perfectly good applications at free or even $0.99. Admit this – comparing a $0.99 app to a $2.99 one, both with similar features, ratings, and quality user interface, which one are you more likely to buy? If you were the guy selling the $2.99 app, wouldn’t you feel compelled to lower your app’s price even just a little? I mean, some money is better than none?

Assumptions

You’re going to make a few assumptions, be it good or bad, but one way or another they will affect your sales. These probably fall into two or three areas, 1) lowering your price will communicate better value; 2) lowering your price will increase sales; 3) more sales means more profit.

Better Value?

That’s open for debate. Customers may think they’re getting a great app for cheap (high value), or they can see a lower price (whether your are lowering the price or setting a low initial offer) and think nothing of it because everything else in the category is priced roughly the same.

Increased Sales?

This might also be true. It almost goes without saying – people can buy more cheap apps on the same budget than pricey ones. I’ll give you a +1 for remembering the concept of supply-demand curves you learned in your high school econ class. There is, unfortunately, a wrench thrown into your increased sales equation – anecdotal evidence points to the best sales occurring right after launch and eventually falling off after the 60-day mark. We’re working with a limited time frame to make the most we can.

More Sales, More Profits

All things being equal this becomes a matter of math. Cutting your app’s price in half means you need to double sales to make the same amount of money. Do you think you can do that? Realistically? In the 60-day window where most developers see the largest chunks of their sales?

Closing Thoughts

I’m going to finish up with one thought that should bring this full circle. Before pricing your app consider the cost of the downward price war. You may make more sales, but you won’t make a decent income off of it. Should this trend continue, our users will become spoiled enough that they will hardly tolerate higher priced apps unless they are truly unique and worthwhile. This price war is only hurting ourselves and something will have to change or the App Store will end up a wasteland of low-quality apps because the true developer dollars will go elsewhere, thus making the iPhone/iPod Touch platform much less appealing for everyone.

Compile Multiple App Versions in XCode

Well on my way to becoming comfortable with Objective-C and Cocoa, I came across the need to create two versions of an app I was working on – one a “Lite,” and the other a full version.

Branch merging scares me

Like any good developer, I use source control management to keep tabs on my development cycles. This time, being no different than any other, I dutifully created a new branch for a lite version of my application once I completed the critical features milestone. Being one who doesn’t have a lot of use for branching in most projects, I was reluctant because (be honest here) the notion of merging back and forth between the lite and the full branches was a painful one.

Ok, I know – merging shouldn’t be that big of a deal, but what about this scenario? I’m adding some features to the full version that I decide I want to port back to the lite. Auto merging isn’t going to work (we can give the lite app all the same features of big brother), but neither am I so keen on going line-by-line every time I make a change. Cry me a river, right? Well, no. Actually, the solution is easier than that.

Enter: Compiler flags

I don’t know when I first learned about it – it could have been in my early programming days when I was learning about C – but I’ve always had ideas about compiler flags in the back of my head… very dim ideas. Look through Cocoa demo apps (check your Cocoa docs) and you’ll see several that have lines of code that seem to point to something specific:
#if defined(LITE_VERSION)
//do something here
#endif
That’s a compiler flag. That’s the key to getting your lite version separated from the full version at compile time (or runtime, or whatever, depending on your need). Using those compile flags you can separate specific portions of code for one version of your app to another.

I’ll save you the dirty details of how you do this. Instead, head over to Junda Ong’s blog.

My First Native iPhone App

It’s Thanksgiving Day weekend – one of my favorite of the year – because it gives me the chance for some nice, quiet R&D time without the pressure of clients or projects asking to get things done. This week I finally made it through enough of my Objective-C/Cocoa/iPhone books that reading further felt like I was just going over more specialized use cases. For now I don’t foresee the need to have covered every topic before I get started – the basics are covered.

Of the app ideas I had going into this weekend, I chose the simplest (training wheels – crawl before I can walk, right?). It’s a Tabata timer for interval-based workouts. Nothing too special. The basic functionality is there, but I want to pretty it up and add a couple features before submitting it to the app store. I doubt it’ll really make me any money, but I did it for the exercise, not for the big bucks. I’ll post screenshots and links when it’s finished/up.

Installing PEAR Libraries Locally

[I started this post quite a while ago and forgot about it. Here it is finished. Hopefully you find something useful here]

I’ve had a few projects already where I could really use some PEAR libraries but not sufficient enough access to the server so I could install them in the system-wide PEAR include directory. I went searching for an easy to manage way to package specific PEAR libs along with apps I was building and installing for clients – something that would work without access to system-wide PHP/PEAR setup, and even in rare cases where I couldn’t write outside the document root.

First place to at least read through is the documentation. I’m going to assume you already know the basics of PEAR.

This summary will discuss the FTP method, as it seems applicable to more situations. For me – I keep my sites under version control so I need to be able to perform a local install that I can commit to the repository and either export or update on my various server environments.

Tools:
* Terminal or command-line (CLI)
* CLI version of PHP
* CLI version of PEAR

Steps (code follows)

1. Create a directory where you want the PEAR libs installed. Note: PEAR will create a directory named pear in the location you specify.
2. CD into that directory.
3. Create your config file for your local environment (probably won’t be needed on external servers unless you plan on installing from there, in which case you should create a separate config file for each site).
4. Install and update packages.
5. Update your app’s include paths.

The Code:

1. Create your config file in the PEAR directory from step 1, above. Absolute paths, absolutely!

   %> pear config-create /path/to/app/htdocs/includes /path/to/app/setup/pearrc

   The first path is the location where you want the files. The second path is the location where the pearrc file is located. I usually put the PEAR files in an includes directory within the site’s document root, just in case a host or client I’m dealing with doesn’t have write access in higher-level directories. It’s best to keep the pearrc file outside of the webroot, or deny access to the file via Apache’s Allow/Deny directives.

2. To run PEAR commands on your local install, you will need to use the following format

   %> pear -c /path/to/app/setup/pearrc [command]

   (otherwise you’re likely working on system-wide changes – doesn’t help you when it’s time to deploy to the server). An example,
   %> pear -c /path/to/setup/pearrc install File_CSV_DataSource

3. Set your app’s includes path to search in the PEAR directory:

   set_include_path(DOCUMENT_ROOT."/includes/pear/php".PATH_SEPARATOR.get_include_path());

   Change as needed.

That should do it. It’s a basic introduction, but if you already know how to use PEAR, you’re already 95% of the way there.