Tag Archives: iOS

Vesper Pricing

A wonderful bouquet of flowers.Q Branch: “Now that Vesper supports all iOS device layouts, we’re raising the regular price for the app to $9.99. With fast, reliable, unlimited sync, we think that’s a great value.

I think the idea of a sustainable business is the right way to look at this, but pricing an app at $9.99 isn’t the proper solution. The proper solution is to charge for their “fast, reliable, unlimited sync.” That’s the value, the app is just a way to get to your data.

The idea of apps is wrong footed, it’s about services. Mobile and Web are the two important clients in that equation. Sure, having a native Mac app would be fantastic, but Web is a better choice to spend your time on, especially for a note taking application.

Here’s an example; Evernote. The value of Evernote is the ability to not only take notes, but get to them from Mobile and Web. We pay for the backend service to keep our data secure and easily accessible. At $45 per year it’s a real deal.

A better play for apps like Vesper is an annual subscription service.

AppKit is to the Windows API…

OMG NEW FRAMEWORK!

Will write C/C++ for foodThere was a lot of buzz generated around the discovery of a private framework, called UXKit, that shipped with Apple’s upcoming Photos for Mac app. Like many others I initially thought “It’s about time.” Then I started thinking about the transition that happened when Microsoft created C# and .Net. At the time we had the Windows API and our trusty C/C++ compiler. At the time .Net shipped in early 2002 we were still building desktop applications, the web was moving forward, but not at the pace it is today. Microsoft shipped WinForms, which was pretty much a straight wrapping of the Windows API’s for .Net developers. The point is, Microsoft gave developers a way to do stuff with the new language and runtime that could get them up and running quickly. The environment was different, but the API’s felt familiar.

Moving Forward

In 2006 Microsoft released a new framework called WPF (Windows Presentation Foundation.) This new framework made use of DirectX so rendering the user interface was hardware accelerated, along with other nifty stuff. As far as I know this was the last major framework Microsoft created for desktop developers. Since that time web development and Surface (Metro) seem to be their primary focus. (Someone please correct me here, if this is not accurate. I’m not that dialed in to Windows desktop API’s any longer.)

The point is, Microsoft went through this weird transition from the Windows API to a intermediate (WinForms) to their final desktop UI framework over the course of four years. Creating new technologies and frameworks is hard. They take time, but Microsoft is good at API’s, and they’re very good at maintaining them and providing developers an upgrade path. This is, I believe, where Apple is today. They’re in that awkward period between AppKit and whatever is next.

Enter Swift

In the summer of 2014 Apple gave developers a great surprise at WWDC. They introduced us to a new language; Swift. Since that time Apple has created a weblog dedicated to the language and shipped Xcode 6 with full Swift support. At this point in time it seems like Apple is pushing hard for iOS and Mac developers to adopt Swift as their primary development language. They seem to be “all in.”

Get to the point

Long story short. Do I believe UXKit is a future version of UIKit for Mac development? No, I don’t. I believe it’s a private framework created by the Photo’s team (or another team) to allow them to share a bunch of code with the iOS counterpart. It makes sense. Apple traditionally operates very lean. They have very small teams, so they need to work as fast and smart as they can. If they have a framework that allows them to share more code, it may allow them to move more quickly.

Ultimately I believe we will get an entirely new framework. Built from the ground up using Swift. I suspect that framework will aim to share code between iOS and Mac where it makes sense, and diverge where it doesn’t. The overall feel will be the same for both platforms. It will be unified.

I love thinking and writing about future technologies. I’m rarely ever right in my guesses (see my musings on WinRT), but it doesn’t stop me from dreaming.

My New Job

I’m happy to say I’ve landed a new full time iOS Development position with a great company; Agrian. They’re a smart and fun bunch focused on creating useful solutions for the Agricultural industry. We live in the great San Joaquin Valley of California, it’s the richest agricultural land in the world. At Agrian we’re “…dedicated to helping all participants in the agrifood industry to grow and harvest crops that are safe, profitable, and comply with a host of state and federal government regulations.” It’s all about making things better for farmers, which in turn, will benefit all of us.

Agrian understands web scale solutions and realizes it’s all about services. Mobile is one tiny cog in that machine and I’m happy to be a part of it.

On the technical side of things I’ll get to use all kinds of nifty stuff day-to-day. We are, of course, using a lot of Objective-C but there is a nice little mix of Swift in the code base, I’m sure that will increase as we move forward. We’re also using some very interesting frameworks. I hope to share more on those later.

The group of developers I’m working with are top notch, all of them. I hope I can live up to expectations.

Regarding Swift

ZDNet: “In essence, Apple had one job — create a new baseline tooling for iOS and show a sympatico approach with how the rest of the industry actually operates — and they blew it.”

I don’t know anything about the author, but based on his statements I have to conclude he’s never written a line of production quality code in his life.

The last thing we need is a lowest common denominator language to allow iOS developers to make code that runs on other platforms. Ridiculous. We have the web for that. If you want a lowest common denominator experience, create a “responsive” website with JavaScript and be done with it. If you want the best experience, go native, with native tools.

Would C# be great on the platform? Yes, but there is no need for the .Net runtime because Cocoa gives us everything we need and it’s not garbage collected. No need for the additional overhead.

If you’re ok with the Xamarin approach, which is very nice, then you should, by all means use it. There may come a day when I’ll have to create an app that works for both iOS and Android and that may be the best approach, until then I’ll focus on learning the native platform tools so I can provide the best experience for my users.

All kinds of crazy

Microsoft Cash Cow.Macworld: “While I was visiting the Microsoft campus a few weeks ago—in suburban Redmond, just across Lake Washington from my beloved Seattle—I kept thinking of the old Vulcan proverb: “Only Nixon can go to China.”

If Microsoft is China, then that makes me Nixon in this story, I realize.”

Quick thought.

Apple should buy Microsoft.

Yes, you read that right. Apple should buy Microsoft for their web services; Azure Mobile Services. Maybe, just maybe, they could leverage it to make iCloud what it could be.

My Favorite iOS Apps

I was trying to convince someone at work that we needed to do some iOS Apps. During the conversation I said something I always say about native iOS Apps. They provide the best chance at a great user experience. He asked to give him some examples of great iOS Applications, so I thought I’d share them here.

  1. Twitterrific
  2. Instapaper
  3. Instagram
  4. Camera+
  5. Evernote

I use the applications above more than any others on my phone, but I have a few from some other companies that I really appreciate. Enjoy.

  1. Tapbots
  2. Appcubby

Atwood on Apple

Red SockJeff Atwood: “But as a software developer, I am deeply ambivalent about an Apple dominated future. Apple isn’t shy about cultivating the experience around their new iOS products and the App Store. There are unusually strict, often mysterious rules around what software developers can and cannot do — at least if they want entry into the App Store. And once you’re in, the rules can and will change at any time. Apple has cracked down several times already:”

Jeff, it’s ok to feel this way. You have other vendors to choose from. Android and Windows Phone 7 to name a couple of great ones.

I’m an iOS developer, not a popular one like Marco Arment, but an iOS developer all the same. I’m ok with giving Apple a 30% cut of my revenues. It’s a part of doing business. I benefit from their infrastructure. They’ve given me store space, server space, they’ve provided a way to install applications and manage upgrades, and they collect money for me so I don’t have to deal with credit card companies and the like. It’s not such a bad deal.

Now, I’m not disparaging Jeff for his opinion on the matter. It’s like a lot of things in life. We have different opinions. He just can’t live with the idea, and that’s perfectly fine. Jeff has contributed a lot to computing and computer science and I look forward to reading his insightful articles for a long time to come. I just may not agree with him. (Psssst, that’s ok.)

ARC

ARCMike Ash: “That, in essence, is what ARC is. The memory management rules are baked into the compiler, but instead of using them to help the programmer find mistakes, it simply inserts the necessary calls on its own.”

Reference counting is a pain in the keister, until you understand the rules. ARC is going to become an important tool in the quest to creating error free code. If you’ve ever written ref counted code you know how careful you need to be so you don’t leak memory or double-release something and cause a crash. It can be frustrating if you don’t pay attention.

This is a welcome change and one I’m looking forward to.

I think it’s time for an RxCalc refresh anyway. Plus some other nifty things I’ve been working on, that will definitely be ARC’d and Mac OS X Lion / iOS 5 only.

Dear Steve

Craig Hockenberry: “I’m one of the developers that is affected by the Lodsys patent infringement claim. I’m writing not to beg for your support, but rather to give you a better idea of how this legal action affects the average iOS developer.”

Go read the entire article. Craig gets to the point. Paying this troll won’t break the bank, but it opens the door to others.

Something else to keep in mind. Lodsys reserves the right to increase their licensing fee at any time. So, what if 0.5+% goes up to 5% of your revenue, or 10% of your revenue? That would definitely hurt the ecosystem.