Again, I want to reiterate that I really do like a lot of what Google does. In fact when forming my company (Fingertip Tech, INC), Google was one of the main role models I had in mind — at the time Google was one of the few non-Linux focused companies that was making a real effort to bring open-source software and values to a more mainstream market; that is a tact I’ve taken and tried to expand on by open-sourcing as much of the software that I right as is feasible. Google’s dedication to pushing the web and mobile forward is nothing short of expiring.

The problem is that I can’t really know what I am paying for the amazing software that Google offers, since I am not paying with currency that I can track but rather my personal information. In a perfect world, I’d be able to purchase Google services ala carte and opt out of all of the “signal generation” aspect of Google. This, however, is not likely, since the data is probably more valuable than any fee that they could effectively extract from any meaningful percentage of the population. I’ve been beating the “pay for software — don’t be the product” drum for some time now, but it seems that the market would just rather not pay for certain percentage of software. Is it time to stop fighting the tide?

Questions? Comments? Dogmatic rage? Find me on Twitter and Google+. This post was brought to you by Code Journal and Fingertip Tech, INC.

Play Games looks really impressive, but the most attractive aspect of it is that it is a backed Game Center like service that is not run by Apple. Let’s be honest, Apple makes great devices and some pretty good client-side software, but their backend services leave a lot to be desired. Game Center in particular was crippled when Letterpress — one of the first games to actually take advantage some of Game Center’s more advanced functionality — was released and became an overnight success. The reality is that Apple left this door open by not focussing on backend-technologies and now Google is going to be able walk through it.

If Android is able to generate roughly the same revenue as iOS for developers, Apple will have to act quickly to preempt an exodus of developers. This might sound a little overboard, but there is a frustration in the iOS community in all but the most hardcore Apple fans that Apple’s policies are increasingly hostile toward independant developers, but as long as the business case is strongly in Apple’s favor, Apple can do whatever it wants. If Google was able to change the business story, they’d be changing the entire landscape.

One of the most obvious ones is familiarity with the platform, development environment, and language. In my particular case, Cocoa and Objective-C are by far my favorite platform / language combination. That doesn’t mean that there is anything wrong or I think badly of C# / .Net or Java — in fact, I often find myself defending Java against folks who spend far too much time reading alarmist Reddit posts. All it means is that I am most efficient in Objective-C. As they say: “Time is money” and sometimes shipping fast is important and the time it would take.

Increasingly, platform vendors are adding features to their platforms that can (generally speaking) only be accessed via the native API — an example of this on OS X is Notification Center. Sure, it is possible to write a wrapper around the Cocoa API for Notification Center, but that’s usually harder than you would hope and adds maintenance to your project that (in most cases) would not be put on the individual developer.

Some projects just market better on specific platforms. A lot has been discussed about the marketability of apps on Linux in particular, but I really don’t think that the conversation needs to center around Linux but should rather be about the tastes and norms of users of each respective platform. For instance, it is usually tough to sell an OS X app to a Mac user that doesn’t “feel native” but that problem doesn’t generally exist for Windows or Linux users.

Developing software for multiple platforms presents its own issues and often takes more financial resources than honing in on a specific platform. The sad fact is that if ISVs (independent software vendors) regularly poured more resources into cross platform development, we would eventually have fewer unique applications released.

I hope this provides a bit of clarification and rest assured that I, like most developers, do not hate your chosen platform and sincerely wish I could easily have my software on as many platforms as possible.

- (void)createNotificationForPomo:(TSPomodoro *)pomo
{
	UILocalNotification* notification = [[UILocalNotification alloc] init];
	notification.fireDate = pomo.fireDate;
	notification.alertBody = [NSString stringWithFormat:@"Nice work! Pomodoro: %@ is complete!", pomo.title];
	[[UIApplication sharedApplication] scheduleLocalNotification:notification];
}

// Now let's remove all notifications
- (void)removeNotifications
{
	[[UIApplication sharedApplication] cancelAllLocalNotifications];
}

Notifications like the one created above will still fire if the app is in the background, however, if you don’t want them to fire if the app is active, you will have to deactivate them on willResumeActive.I hope this helps you and that you reconsider how often you send user data over the air and use UILocalNotification as a simple alternative to push when appropriate.

Comments? Questions? Drop me a line on App.net, Google+, or Twitter. Also, pickup Code Journal.

Hope you like it!

This post was brought to you by Code Journal – available now on the Mac App Store. Questions? Comments? Find me on Twitter or Google+.

Yes, I know Apple has changed the world! Users now demand simple and elegant experiences. Isn’t that great? Well, no if you’re a developer, that’s terrible. That’s terrible, because, as a developer, you likely do not possess the design skills or experience to properly design an app of design caliber that a professional designer would. Like developers, designers do not work for free and a gifted designer who has been working in the field for any length of time command and handsome hourly rate. That means that to hit the required level of design, developers need to invest a good deal of capital in it.

Let’s say that you’ve got your design down and you’ve come to terms with your newly shrunken bank account – my condolences on that by the way. What now? Do you just passively wait for users to download your app? Perhaps you pray for users? Do a rain dance? Sadly, there is no evidence to suggest that any of the preceding will actually help your app become successful. Like any product (and yes your app is a product, not some work of self-expression), your app needs to be marketed. There are a lot of ways of to market it an app, though few of them are effective, but none of them is free unless you are a known quantity (like Arment) or able to convince one to push your app. That means you will need even more capital to get advertising for your app.

Like Arment, I agree that the bar is higher for apps than it was just a few years ago, but I contend that the bar being higher is a problem for the average independent developer. Many of these developers simply do not have the capital required to hire a decent designer and effectively market an app. So, if Arment seems to agree that the bar is higher, then how could he be so blind to the issues that poses for small independent developers? The answer is surprisingly simple: Arment is something of a celebrity in the Apple developer world. That means he doesn’t need to spend the capitol that others would to market his apps; In fact, his name and connections do that for him. In short, the bar is higher for all of us, but it is only half as high for Arment.

Still, I am not deterred from the field and hope you will join me in toughing it out. There is still a lot to be happy about in the industry even if some of it (app store distribution) comes with some serious strings attached. It’s a bit funny in fact – as I lie here thinking of all the things wrong with our industry I am also planning out what coding projects I want to work on over the weekend.

I hope this post has brought some value to you despite it being basically a stream of consciousness – if you do like it and have comments, please leave them on Google+ or Twitter.

SourceTree: Though I generally use the command line on Mac for Git, on Windows I prefer to user a GUI and there really isn’t one out there that performs better or is as simple to use as SourceTree. To put it simply, it is the best looking Git client on Windows and is totally free of cost like its Mac counterpart.

Visual Studio: I’ve said it before and I’ll say it again: Visual Studio is a great IDE. Currently, one of my projects is focused on Windows Azure, so Visual Studio was the way to go. So far it rocks.

PowerShell: I have to admit that before Windows PowerShell hit the scene, I always felt that Windows was just a little too GUI focused. After all, on my Mac I can write a little Ruby script or Bash script to solve whatever lame problem I am problem I am having – these problems usually have something to do with improperly named assets from clients (as an aside, please follow the naming conventions I prescribe) that I have loop over and mass rename. Admittedly, I am a PowerShell novice, but so far it rocks I can do just about everything I used to do with a Bash script with roughly the same amount of lines in PowerShell.

That’s it so far. Obviously, I could use a few more tools on the Windows side and if you have any suggestions, please send them my way. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.

Currently, Blink and Webkit are just about identical, so we can still feel secure in our Webkit “monoculture”, but the situation will likely change in a year or less. Even if Google makes an effort, as some have suggested that they might, to not break standards or chooses not to push Blink specific features, web developers are still going to have to deal with yet another rendering engine. Sure we’ve already been dealing with a number of them and have gotten used to having to append our CSS with “–webkit” or “–moz”, but Google is not adding a “–blink”. Instead, developers will have to dig into a settings screen to enable or disable functionality. Bottom line there is that there will be Blink specific functionality that some developers will likely want to user; for example currently NACL only works on Chrome and Dart VM works best on Chrome – in other browsers code written in Dart has to translated into traditional JavaScript. There are also a number of rumors floating around that Blink may focus on optimizing HTML5 graphics performance on ARM devices.

The question really becomes not what Google is going to do with Blink but rather what are the rest of the Webkit team going to do without them? Google and Apple have been the driving forces around the project and more and more Google has been taking point on a lot of the more cutting edge issues; for example, Google has been pushing performance more than any other contributor to the project but, for the most part, Apple and others have been able to benefit from Google’s efforts thanks to the free software nature of the project’s license. Given Apple’s less than enthusiastic embrace of developers using web technologies to develop for their platforms, it seems unlikely that they would be inclined to match Google’s pace. In a lot of ways, give that Apple’s business model is to sell expensive hardware, a good browser is just another feature on an Apple device, however, for Google, the browser is the primary platform.

Progress is a good thing for web and I am confident that Google’s decisions will yield web developers some pretty cool tech to work with, but there is also the risk that web developers will start relying on those tools too much and we will end up back in an IE 6 / ActiveX situation. Questions? Comments? Dogmatic rage? Please feel free to contact me on Google+ or Twitter. This post was brought to you by Code Journal for Mac.