Tag Archive for osx

A Swift Softening

enter image description here Listeners to last week’s Coder Radio know that during the live feed WWDC coverage, I was less than enthused with the announcement of Swift, Apple’s new programming language for iOS and OS X. My initial reaction was based on the somewhat unclear way they announced Swift; it was not very clear what they wanted us developers to use Swift for and that led me to the wrong conclusion that Swift is designed to be a near to medium term 100% replacement for Objective-C – this simply is not the case. So far, I’ve read through the Swift book on iBooks and the documentation publicly available twice and found something very surprising – Swift reminds of QML in QT.

This might sound a bit odd, given that in a lot of significant ways Swift and QML are very different languages, but they actually share a kindred spirit and will likely take the same place in my tool-chain – layouts. Yes, both Swift and QML are technically capable of so much more than layouts but really they are both well suited for that task in particular. Why do you think the WWDC demo was so UI / visuals heavy?

So the bottom line is no I don’t hate Swift and no I don’t think it will be the end of Apple development as we know it. And yes, I will be using it but, at least for the next year or so, in the same capacity as QML and its relationship with Objective-C will be same as QML’s with C++ in my QT code-bases.

Questions? Comments? Find me on Twitter.

Code Journal 1.4.0 Update

Code Journal LogoI am Happy to announce that Code Journal 1.4 has just been released on the Mac App Store. We took special care to respond to your feedback both in terms of performance and of course new features.

I am particulary fond of the new less wordy way we are naming and dealing with repositires in the title bar and also we’ve added the match requested manual refresh button. For a more complete list of changes, please see the release notes on the App Store.

2014 Predictions

I hope that you have all had an awesome New Year’s Eve! I’ve decided that I’ll start off 2014 by making a fool of myself by trying to make some predictions for the tech industry for the new year. This is not a what you will see list, but nor is it a what you won’t see one; in reality, I am trying to focus more on trends than anything else. Overall, 2014 is looking to be a transition year rather than a real game-changer. This is in no way a bad thing and makes sense for where we are in what is usually a twenty year tech cycle; it is important to remember that the mobile revolution is not even half way done and there are still a lot of incremental advancements that need to be made in that area before it can be considered complete. Still, this article will not focus on mobile exclusively but will rather jump around with no other aim than what I find interesting.

Docker: Docker is the darling of the developer community right now and for good reason — it solves a problem that (outside of the BSD community) hasn’t really been properly addressed. There is however a risk of certain segments of the community drinking a little too much of the Koop-Aide and using Docker in ways that it wasn’t intended to be used; just think about what we saw with Rails a few years ago and the hype surrounding that and you will have a good idea of what I am concerned with. Still, at the end of the day Dockery is going to be a major tool in a lot developers’ (including this one’s) toolboxes for 2014 and probably beyond.

Windows 8: In the consumer market, Windows 8’s RT offering is in a lot of trouble — that is undeniable at this point. Windows Phone suffers much the same fate as Windows RT, though Windows Phone does enjoy a good holding in South America and some other parts of the world. Microsoft has already hinted strongly that they plan to merge WinRT and Windows Phone into one mobile operating system alla iOS. This is a great Idea but is several years too late. It also undermines the “one Windows” pitch that Microsoft has been making for Windows 8 over the last few years. In 2014, Microsoft will still be dealing with the fallout of their bumbling launch and marketing of Windows 8.

Azure: Azure has grown far beyond Windows in the cloud and at the close of 2013 is a rival to Amazon Web Services and pretty much every other cloud offering. I’ve used Azure several times myself over the year and am pretty impressed on the whole; there were some bumps in the beginning and middle of the year, but these have largely been addressed and it looks like Microsoft has some ambitious plans for Azure in 2014. Over the last month or so something called Midori has been leaking out of Microsoft and, though the pundits seem to think it is something to do with Windows on the client-side, my bet is that this is some sort of evolution of Microsoft’s cloud offerings. Either way, 2014 is going to be a good year for Microsoft in the cloud and for Azure.

Mac OS X: Twelve months ago it looked like OS X was veering dangerously toward an iOSification that would have proven intolerable for professional users. With Mavericks however Apple has found a good balance between their desire for control and the reality that the pro-market has been driven to OS X due to its being a UNIX system that has a late vendor for support and an attractive user interface. Despite the apparent back peddling, it is important to note that Apple has gotten one major change in the OS and managed to implement it in a way that is both useful to the average consumer and acceptable to the pro users — this feature is called Gatekeeper. In Mavericks, Gatekeeper does not allowed unsigned applications (to sign an application one needs to be an approved Apple developer) to be installed on the system by default. The key is that this is a default that any sophisticated user can change. However, I must admit that I have kept this default. Going forward, Apple’s belief in signed applications (or perhaps some slightly watered-down version of it) makes a lot for sense for the future of computing and I actively support refusing to install unsigned applications from untrusted sources. If the current path holds, Apple will be balancing making OS X simpler for average users and new users who came over due to the halo effect of iOS while balancing the needs of the professional user market.

Ubuntu / Linux: Canonical has done an amazing job of sullying the Ubuntu name over the 2013 and has done little more than make a fool of themselves with their naïve attempt at breaking into the mobile space. Ubuntu will still be a very popular desktop Linux operating system among new Linux users and will continue to be a major player on the server-side. Canonical the company however will fail to monetize their offerings in any significant way. The only ray of hope would be some sort of re-focusing of the company to be an enterprise focused organization much like Red Hat. Even in that case, Canonical will not be able to be a true challenger to Red Hat in 2014 and it is unlikely that they will even decide to try. The continued flailing of Canonical will contribute to a “brain drain” of passionate and talented Linux enthusiasts out of the Ubuntu community and into other Linux communities. Another side of effect this is that desktop Linux will continue to be the proverbial tempest in a teapot that it has always been. This internal discord will guarantee that 2014 will not be the year of the Linux desktop in any significant way.

That’s it! Those are my foolish predictions for 2014 — foolish as they may be, I am pretty confident that most of them will be, if not correct, then on the right track. I know they are not earth shattering and basically boil down to 2014 will more or less maintain the status quo. In a way, that’s a good thing. If we are constantly reinventing new technologies and never refining the technologies we are already have, then we will always be using unstable and half baked first generation technology. Have a happy new year and feel free to comment on Twitter.

Lessons Learned: Code Journal Early Release

As you may know Code Journal had its early release last week and it has been a pretty good experience so far. I got lots of great feedback from users and have already been able to update the application based on that feedback.  The purpose of this post is to share some of the lessons I have learned and create a discussion around independant software development and distribution. I could enumerate all the nice things that have been e-mailed or otherwise communicated to me re Code Journal, but I believe that there is more to be learned from criticism than praise, therefore, I am going to discuss some of  the application’s critiques.

Critique #1: Mountain Lion Only!?!?
Yup, I heard this one a lot. I decided to develop the application for Mountain Lion, because I thought a few 10.8 specific features were essential and that most of the application’s users would quickly upgrade to the new OS. Turns out that even though Apple reported record adoption of Mountain Lion (OS X 10.8), a large set of Code Journal’s potential users are running older systems: mostly Lion (OS X 10.7). The good news is that despite my miscalculation, I was able to rectify the situation quickly; I have already updated the app to support 10.7+ and I am happy to say that the updated version has been live for several days now.

Critique #2: No Pasting Passwords?
This one caught me a little off guard but really it shouldn’t have looking back. You see I have this odd habit of memorising long passwords, so typing them out is a pretty routine task. Most sane people, however, are using something like LastPass or a similar tool. I am happy to report that I have an update to Code Journal in testing that does allow the pasting in passwords and, unless any issues are found, that version will be pushed live early this coming week.

Critique #3: No App Store Version?
If you are a Coder Radio listener (and you should be), you will know that I am doing something of an experiment with Code Journal. Basically, I have not released it on the Mac App Store intentionally to see how that would affect sales and what (if any) feedback I would get regarding its distrobution. Before I mention what feedback I got I should say that this was the single most common critique of the app. In short, a lot of people have a strong preference to get all of their apps from the Mac App Store and do not want to purchase apps from a website. This is good news for Apple, but bad news for devs; I still hold that there is significant value in having a direct relationship to the users of your apps and the delays caused by Apple review process (22 days for Code Journal’s first binary) can be incredibly damaging if your strategy is to build and iterate rapidly. Assuming that the feedback I received is representative of the greater Mac user ecosystem, it seems that the Mac App Store will soon be the only feasible portal via which to sell apps; barring games that might do well in Steam.

Critique #4: What is Gumroad and Why Isn’t It PayPal?
This is another one that really surprised me, but it seems that there a lot of users who are not really comfortable entering their credit card data into Gumroad. Taking a high level look at my data I have x sales but x * 30 sales have ended right at the checkout screen. Think about that for a minute. The vast majority of people who like the info page enough to click “buy now” got all the way through the checkout process and turned back at the final checkout screen. The data aside, I have heard from several people that they or others close to them were not comfortable with entering the credit cards into Gumroad and would strongly prefer that I switch to PayPal. So why Gumroad at all? Well, they do a lot for me for the same cost as PayPal including verifying receipts, sending app updates to users, and a number of other small things that I would have to implement myself with PayPal. I am still considering how to handle this issue.

Bottom Line
In many ways I feel direct distribution has been incredibly successful, mainly because it allowed me to react quickly to user feature requests (back porting to Lion etc), however, the Mac App Store issue is a troubling one; if the percentage of Mac users who strongly prefer to purchase apps via the Mac App Store continues to grow, developers will have little choice but to conform to the somewhat draconian sand-boxing policies of the Mac App Store. Having said that, I am not against distributing Code Journal via the Mac App Store. In fact, if the numbers continue as they have (numerous users declining to purchase until an a version is on the store), then I probably am not going to have much of choice.

Comments? Questions? Find me on Twitter or Google+.