Tag Archive for Mac

Code Journal 1.3.4 Update

050413_1245_CodeJournal1.pngCode Journal 1.3.4 is now available on the Mac App Store for free. This update includes a number of small bug fixes. There are a lot of big changes coming to Code Journal over the next few months and I think it is really going to take the app in a great direction.

I’ve taken your feedback on the app and in particular feature requests and, though no new features are included in this update, new features and the restoration of the Gist functionality is on its way.

Stay tuned for more updates!


Thank You!

Code Journal LogoCode Journal has done extremely well on the Mac App Store recently. It reached as high as number 31 for free apps overall and number 2 in its category. Needless to say I was shocked by the sheer number of users downloading the app. For the most part users are happy and the app is working as expected. However, there have been a few issues that have cropped up over the last week.

Like many API providers Github limits third party developers to a certain number of API tokens and requests per time period. What this means in real-world terms is that if you are a third party developer, like I am, and you see rapid adoption of an app that hits their API, you may start to see some issues for some users. This issue has been further exacerbated by the fact that iPhone version of Code Journal currently uses the same tokens as the Mac version available from the Mac App Store and my site. Steps have been taken to resolve this issue on two fronts: one Code Journal for Mac now has more tokens and two once the next editions of the Mac app and iPhone app are approved, they will be using different tokens — essentially doubling the pool for both apps!

I’d like to personally thank all of you for giving my little app a shot and I would especially like to thank those of you who have emailed me your constructive feedback and were patient during the token drought. Your continued support has meant more to me than any chart ranking and I am happy to report that I will be releasing another free app on an Apple platform in the coming month or so. Stay tuned! And thanks again!

I welcome comments or replies to this thread on Twitter or Google+. If you haven’t already, download Code Journal from the Mac App Store.

The Best Feature…

Code Journal LogoI’ve been hard at work mapping out the future of Code Journal  and took some time to go through user e-mails that requested new features; the idea was that I would simply implement the feature that the most users had e-mailed asking for. That feature was a resizable UI.

The problem was that the people, my customers who I of course care a great deal about, were very passionate about this particular feature and the feature seemed simple enough to implement; after all, I’ve implemented resizable UI’s on a number of Mac OS X apps for clients, so why couldn’t I apply the same the techniques to Code Journal? Right? Wrong.

Code Journal started out pretty simple; it was an app that pulled and processed JSON data from the Github API; in fact, the most complicated thing in the private demo (think alpha) version of the app was Github’s OAuth. I was thrilled. The app was nice and simple.

Overtime and as it closer to the all important 1.0, compromises had to be made. There is no need to enumerate them here, but suffice it say that one current feature (Github Enterprise support) is responsible for a disproportionate amount of code and almost all of my support requests. Does that mean I’ll be pulling enterprise support? Absolutely not. The truth is that these request have more to do with customers having non-standard settings on their Github Enterprise deployment or the server that host them, rather than anything to do with Code Journal. Enterprise support is a slam dunk and I personally love being able to user Cde Journal with clients who have Github Enterprise servers; best part is that most of the time all I have to do is fill out the enterprise field in the app with my credentials and we are good to go — no need to bother a sys-admin at all.

In short, the complexity that supporting enterprise customers caused was a good thing. Back to the feature request: resizable interfaces.  I understand why some people might want this feature, but, to be honest, I don’t think it’s a good idea. Even on my 27 inch Cinema Display, I often find myself pressed for screen real estate when tacking some hairy memory management problem or am “in the zone.” Like many of you, I am not willing to compromise by putting my monitoring tools into a separate space and, again like most of you I imagine,  I only have the one screen. The other issue of course is that Code Journal is a Mac app and a lot developers that work on Macs work on 13” laptops.

Still, it’s hard to ignore your paying customers, so I went against my instincts and began coding.  I won’t bore you with the details, but it was doomed from the jump. I spent two weeks coding and agonizing over resizing table views and experimenting with Auto Layout. What resulted wasn’t terrible but had a number of rough edges and, more importantly, was not a feature that I could see myself using and believe would have been a major source of maintenance. The feature is not going to be released. At this point in the product’s life, it is more important to keep complexity out of the equation than to add every suggested feature; this particularly true of features that don’t provide any additional functionality. The best feature is the one you never have to maintain.

Comments? Questions? Share them with me on Google+ or Twitter. This post was made possible by Code Journal and Fingertip Tech, INC. If you are Github user please check out Code Journal and if you are interested in having an Android, iOS, or web app developed please contact me. Also, check out the new free version of Code Journal for iOS.


Pricing: We’re Doing It Wrong

Like many of you I am an independant software developer and have found some success leveraging the App Store. Many developers, myself included, have bought into the low price / high volume business model and we’ve had some mixed results…. I’ve been considering the pricing issue for a while and have come to an odd, but by no means original, conclusion: we are all underpricing ourselves. Please note before you read this that I am excluding games from the equation here

This might sound strange given the rise of freemium software and the general wisdom that cheaper software sells in higher volumes. However, it doesn’t seem to hold up.  Taking a fast look at the current top ten grossing paid applications on the Mac App Store, the average price of an app is $75 and the most commonly appearing figure is $20. Now before you get too excited about that $75 figure keep in mind that the average is shot up by a few apps at $200 or more. Also, keep in mind that I am using the ‘top grossing’ for my metrics rather than ‘top paid’; I’m using ‘top grossing’ because it isn’t clear what it means to be a ‘top paid’ app but an app’s gross revenue is an accepted metric I can use to judge its commercial success.  A few other things I’ve noticed from looking at the top grossers: none of them is $0.99, none of them is $1.99, none of them is even $4.99, and the lowest priced apps are $20.

To be honest, I don’t know what price points we should all be hitting, but anything below $4.99 for desktop software seems like far too low; in truth, I am starting to feel like the $4.99 price point is even a bit too low given how much work we put in our products. All I know is that we (software developers) need to end this race to the bottom on price.

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

Macbook Air for Development

If you have been following me on Google+, you may know that my beloved Macbook Pro had a little accident; I was working late and was extremely tired and I dropped my full mug of coffee directly onto my Macbook. That’s right the entire mug of steaming hot coffee went directly into my almost two thousand dollar laptop. Desperately, I began to dry off the machine and attempted to use compressed air to force out the moisture. I did this for some time  but finally had to go to sleep. All I could do was wait. In the morning it became clear that my machine was a doorstop, so I drove to the nearest Apple Store and made a purchase.


The laptop being replaced is a Macbook Pro 13” i7 with 8GB of RAM. By any measure it is a powerhouse for a laptop; full disclosure it has had some trouble with kernel panicking that I believe were due to overheating.


As usual the Apple Store was jam packed, so I had to wait to speak to an employee, but that was fine, since I had not yet decided what to buy. I knew I wanted an Air; my experience with my XPS 13 has sold me on the virtues of SSD’s and frankly traditional spinning drives feel a bit antiquated to me know.


I also looked at the retina model for a few minutes. I can’t deny that it looks very pretty, but the web is not retina yet and the cost is a bit more than I want to spend; I have been going through a Mac laptop about one every eighteen months, so spending over two thousand dollars on a machine seemed foolish to me. Another point regarding resolution is that the Macbook Airs are all higher resolution than the machine that I was replacing and they look stunning.


If you can’t figure it out already, I bought an Air. I had thought that I needed to have the same amount of RAM as my pro, but, having done some research and having worked on my XPS a bit, I came to the understanding that an SSD really makes the most difference for the type of work I do on my Macs: iOS and Mac development.


For the stat minded, I got the 13” Air with 4GB of RAM and the 128GB SSD hard drive. Or in other words the base 13” model. How’s it going? So far so good.


Comments questions? Find me on Google+ or Twitter.

Effects of App Store Distribution pt1

Those of you who follow me here or on Coder Radio or on any of the social networks that I frequent will know that I have been running a little experiment with my new Mac Application Code Journal; for those of you who randomly got here via a search or something like that, the experiment was trying to sell a consumer target Mac OS X application outside of the Mac App Store. No need to go into too much detail, since if you want more info you can go check out episode ten of Coder Radio, but the experiment did yield a result and a lot of feedback. Basically, there is ample evidence to support the idea that, in general, apps that target OS X will do better on the App Store than via direct sales.

As with the mobile space, I believe that increased reliance on app stores will have some considerable effects on the business of app development, the developers, and the apps themselves. So I am writing this three part series to discuss those issues and am taking something of novel approach (novel to me at least): I am going to look at this issues by comparing two very different apps Mars Edit, and my own Code Journal. I picked Mars Edit as a point of comparison because it is established and is in a different space than Code Journal, so there isn’t any risk of bias. Additionally, in many ways Mars Edit can be seen to represent the traditional Mac application model while Code Journal more closely resembles the single purpose “app ideal”.

The eight hundred pound gorilla in the room is app pricing. In general it is becoming increasingly hard to sell an app for more than a few dollars; some would argue that even getting the few dollars at all is really hard. Of course, there are exceptions to this, but those tend to be from either large game companies (think EA, Activision, etc) or from established Mac developers. An example of the latter would Daniel Jalkut’s Mars Edit, an app that is currently selling for $39.99 on the Mac App Store. Mars Edit’s success is a great story but also very atypical of pricing for productivity apps in the store and a lot of that may be due to Jalkut’s and the app’s cache’ in the Mac developer / enthusiast community; again for those who don’t know Jalkut was a former Apple engineer and has been fairly active in the community. Additionally, Mars Edit was successful long before Jalkut took it over; he actually bought the app from another developer in 2007.  A quick survey of competing apps in the same space on the store showed that most of Mars Edit’s competitors tend to be in the ten to fifteen dollar range and seem to have poorer placement in the store, which suggests weaker sales. One notable exception is the $39.99 MacJournal; Yes, there are of course other applications on the store that charge more, such as OmniGroup’s OmniPlan, but  we are looking at its competitors here.

What does this all mean? Honestly, Apple is the only who has the data to be able to truly say if the store if pushing prices down across the board. There certainly seems to be a correlation in applications being priced lower and the rise of the app store model, but there is an alternative argument (with an alternative villain) that could be made: free web apps may be forcing prices of native apps down by training consumers that a large class of applications should be free, such as Google Docs. Again, Apple is really the only who can disprove or prove the first point for sure and the web app debate is something for another day.

Check back soon for a look at what the App Store seems to be doing to independent software developers.

If you have some feedback please find me on Google+ or Twitter. Also, if you like my posts or work on Coder Radio, please consider purchasing Code Journal either from the Mac App Store or direct.

A Look at Control and the Mac App Store

Much like they have in the mobile space, Apple is leading the charge to commoditize software from independent developers, making it more affordable and convenient for users to purchase and keep up to date. The signs seem to suggest that this has on the whole been a boon for most developers but it has also put an unprecedented amount of control in the hands of Apple regarding what apps Mac developers create and what functionality they can and (more importantly) cannot have. Given that control, Apple has chosen to enforce a few policies that are not in the best interest of Mac developers: they refuse to support paid upgrades for large scale apps, enforce a rather rigid and restricting form of sandboxing, prevent developers from using some of the platforms newest and most interesting APIs on apps that are not distributed via the Mac App Store.

Developing software is difficult, time-consuming, and expensive. Traditionally, developers of large applications have used upgrade pricing schemes to maintain recurring revenues as a way to fund future development of their apps; an extreme example of this would the Adobe suite of tools.  Apple currently does not allow developers to charge for updates. Think about that for a second. Users are going to, as they have been trained to for years, expect  their apps to be kept up to date and, in some cases, provide increased functionality as time goes on. However, the current App Store model forces developers to either betray users’ expectations or somehow finance perpetual development of their apps on whatever one time cost they manage to charge on initial purchase; it should also be noted that apps on the Mac App Store have a tendency to be relatively low cost. Some have suggested that developers could take advantage of the Mac App Store’s in app purchasing APIs to make up the lost revenue. In some cases this might be a serviceable option but falls short of being a full replacement for true update pricing. The issue here is that this limitation discourages the continued development of large scale software for the ecosystem.

Security hasn’t been much of an issue for OS X historically. Despite what Apple fans would tell you, that has nothing to do with any sort of enhanced or inherit security on OS X. The truth is that OS X did not have a sufficient install base to make it an attractive target for malware authors. As Apple has been ever so eager to share, Mac sales are growing rapidly when compared to the overall PC industry. In short, OS X is becoming an increasingly attractive target for malware authors. Apple has responded swiftly to these increased threats in what is probably the most excessive heavy-handed PC security policy to date: sandboxing. If you are reading this, I assume that you already know what sandboxing is, so I won’t bore you by reproducing the definition here. In theory, sandboxing is a good way to make an operating system more secure, but in practice, it is more a restrictive mess than anything else. Basically, sandboxing does not provide enough benefits to be worth the onerous restrictions that it imposes on apps’ functionality.

For us developers, APIs are our windows into the platforms we work on. We depend on those APIs being documented, stable, and consistently available. On those first two counts, Apple has done a tremendous job in recent years. However, with the introduction of Mountain Lion, Apple has restricted a number of its newer and more interesting APIs to applications that are sold on the Mac App Store; if you are interested in what APIs are restricted, there are a number of them, but on the whole, they tend to be the ones that have to do with iCloud or the Notification Center. This is something of a Catch 22 for developers, since users are going to increasingly expect apps to provide the functionality provided by these APIs but may not necessarily want to purchase their apps via the Mac App Store. Once again, we have a case of Apple’s policies forcing developers to run afoul of users’ expectations.

What does this all boil down to? Apple’s recent policies make OS X development a lot more complicated for developers who want to keep up with the operating systems newest APIs but also are unable to comply with the restrictions associated with sandboxing. My take is that if you are developing a powerful application for OS X, odds are that you are going to have sell outside of the Mac App Store, due to sandboxing,  and live in fear of Apple one day using GateKeeper to further restrict the distribution of non-App Store apps. For another take on this, have a look at popular iOS developer Marco Arment’s post on the issue.

I know I have made some pretty strong statements here but I stand by them. If you would like to debate me on these issues or have any other feedback, find me on Google+.

WWDC 2012 Keynote Let Down

Earlier today I hosted Coder Radio with Chris Fisher of Jupiter Broadcasting and in the episode we discussed my reactions as a developer to the WWDC keynote this year (2012). First things first. I did not attend WWDC nor have I installed the iOS 6.0 developer release, so some of my information may be incomplete; I have to do this in this way due to Apple’s developer NDA. You can listen to the show to hear what I didn’t like, but I’d rather go through a few things that I would like to have seen that to my knowledge aren’t coming.

Inter-app Communications
This is by far my largest pet peeve with iOS development and using iOS. Why isn’t there are robust way for apps to work together and share data; within reason of course. Android has a version this in the form of “intents” and Windows Phone 7 has a incredibly powerful system called “contracts”. This really gets to me when I consider that iOS is a BSD system yet does not adhere to the UNIX philosophy of allowing many small applications to work together to do big things; yes, I know that iOS apps tend to be smaller in scope than their desktop counterparts but to date there is no real way for them to work together. There is so much functionality that cannot easily be done on iOS due to this restriction.

On my Android and Windows phone I can glance at the screen and get the latest tweets, view other data (such as a stock ticker), and play a song, or begin or pause listening to an audiobook. On iOS, almost all of those things require me to launch separate apps. That’s silly not to mention a bad user experience. I know there are definitely battery life concerns if you have too many widgets open, but there is no reason that Apple can’t add some sort of restricted mode for simple widgets to run in.

Siri integration
Ever since I got my hands on my 4S I have been waiting for a full Siri API. Apple has been working on it, but to date there is no fully functional Siri API for third party developers. This is understandable given how often Siri simply does not work but it is still a shame.

That’s all for now. Now I can finally take a look at the dev preview! For feedback please find me on Google+ or Twitter.

Review: Revolution in the Valley

Revolution in the Valley is the story of that first Apple development team that brought the world the Macintosh and in doing so changed computing history by making the computer a personal item focused on communication rather than computation.

Popular mythology portrays the development of the original Macintosh as a somewhat religious experience. In fact, that was not really the case. As with any large scale project there are problem, conflicts, and unforeseen bugs that raise both costs and tempers. Revolution in the Valley gives the reader what a more accurate account of the not only the development culture at Apple during its early days but also how large scale projects work in the really world when real people who don’t necessarily agree on the best ways to implement feature X.

As this is not a technical training or reference, there are really no prerequisites to reading but that does not mean that more experienced developers or even designers won’t get a lot out of the book; in fact, I always find it interesting to see how those early developers of the personal computer 1980’s  solved  complex technical issues with such limited hardware and software resources; after all there was no Github or BitBucket when the Macintosh was being developed.

In short, I would recommend this to anyone who works on or will be working on larger scale software projects.

For all the Apple haters, I know that my posts have been pretty Apple-centric for the last month or so, but I do have some interesting Android and other posts plans.

Tutorial: Recording Media with QTKit for Mac OS X

Mac’s are very popular among creative professionals ranging from the user interface designer who designed your favorite iPhone app to the starving videographer who is just starting to break into the field via Youtube and Vimeo.

Recently, I have taken the plunge into Mac OS X application development and had a need to implement a number of multimedia functionality into the application: recording video via a built in or external camera and recording audio via the built in or external microphone and a number of other things. One way to this with a minimum level of effort is to use Apple’s QTKit; for those not familiar with Apple technologies QT stands for Quick Time which is Apple’s entrant into the multimedia player space.

There are number of things that you can do with QTKit but I am only going to focus on recording video and audio for this post. Additionally, I am making some assumptions about you, my reader: I assume that you know how to add a framework to an XCode project, I also assume that you know at least a introductory level of Objective-C and will not providing samples of what I consider boilerplate code.

Ok, so let’s get to it. Once you have imported QTKit, open the header file the class that you want to deal with the recording and declare some variables like so:

QTCaptureSession* session;
QTCaptureMovieFileOutput* fileOutput;
QTCaptureDeviceInput* videoInput;
QTCaptureDeviceInput* audioInput;

You are also going to want to create an NSButton to receive a click from the user. Jump into your implementation file and it’s time to start using those objects and making some more to actually determine how capable the system is of recording media. The following code is probably best put in an awakeFromNib or some similar function:

QTCaptureDevice* videoDevice = [QTCaptureDevice defaultInputDeviceWtihMediaType:QTMediaTypeVideo];
if (videoDevice) {
videoInput = [[QTCaptureDeviceInput alloc] initWithDevice:videoDevice];

Ok, so what we’ve done here is create videoDevice and set it to refer to whatever the default video recording device is for the user’s systems; I would be willing to gamble that you will be dealing with the built in camera pretty much all the time, but even if some silly user out there is doing something well… silly QTKit does a good job of abstracting specific hardware concerns away. I’ve omitted a good deal of code from my implementation above that basically does some safety checks and checks to see if the once device that you have found can also do audio recording and if it can assigns it that duty as well. These checks are mostly BOOL checks and simple checks from the hasMediaType method.

Once you have your input device / devices configured it is time to actual configure how the media will be recorded:

QTCaptureConnection* connection;
NSEnumerator* enumerator = [[fileOutput connections] objectEnumerator];
while ((connection = [enumerator nextObject])) {
QTCompressionOptions* options = nil;
if (mediaType isEqualToString:QTMediaTypeVideo]) {
options = [QTCompressionOptions compressionOptionsWithIdentifier:@”QTCompressionOptions240SizeH264”];
} else If ...

Basically, all this code does is create a few objects and loop over some data (I know that’s a pretty hardcore oversimplification but from an implementation standpoint, that is all you really need to know) and then determine how to encode the data to be output. Again, I have shown the code for the video, but the code to encode the audio is very similar.

In the last code chunk I neglected to explain what fileOutput was. Simply put it is an object that, as its name suggests, represents the resulting data after it has been properly encoded. So using that object we can do:

[fileOutput setCompressionOptions:options forConnection:connection];
[session startRunning];

And there you go. Your output will know be encoded to whatever you set in the above loop, so if you kept my code, your video would be in H264. The last line of code should be self explanatory, so I am just going to move on.

Your fileOutput object has one more important job to do: determine where to write the resulting file or if to write it at all. Remember when I recommended that you create a button and an IBAction? Well, you are going to use it now. Put the following code in your IBAction:

[fileOutput recordToOutputFileURL:[NSURL fileURLWithPath:@”/Users/share/movie.mov”]];

Basically, all this does is tell you fileOutput object where to write its data. Fair warning, that last code sample breaks Apple’s new sandboxing rules for the Mac AppStore, so if you want to be in the Mac AppStore, you are going to have to write the data within your application’s own sandbox; see Apple’s developer docs for more details on the new sandboxing rules. Also, the keen eyed coder will notice that my samples require manual memory management, but I did not include and release statements. Be sure to manage your memory properly.

If you have any questions or comments, sound off in the comments. Additionally, I can be reached on Twitter @dominucco.