June 10, 2015

WWDC 2015 PostScriptum

I made a list of predictions and hopes for this year before the Keynote. Now I would like to review them one-by-one with some comments.

iOS 9 ✓

The cool multi-tasking is the biggest surprise. In addition, we got an improved keyboard and the new system font San Francisco. Everything else is good enough for the “snowy” release.

OS X 10.11 ✓

El Capitan is not as innovative this year, because most new features belong to the native apps. Though iPad-like split-screen implementation looks promising. I live on San Francisco in Yosemity for 2 weeks, it is awesome.

Xcode 7.0 ✓

The new version of IDE looks better than ever and got new features for UI testing and IB modeling. Unfortunately, this is still not AppCode in terms of re-factoring, but new features should make us better developers anyway.

Swift 2.0 ✓

It looks like the new version of the Apple language solves most of the problems we had. On the marketing side, Swift is going open-source in 2016. Which means Linux support and potentially a new environment for web development are coming.

WatchKit 2.0 ✓

The new watchOS provides almost the same capabilities as v1 for third-party apps. Although now the apps can be native and work without an iPhone counterpart for business logic. Which is great.

CloudKit 2.0 ✓

Not 2.0 officially, but it's okay to call it the next version. Just a year after announcement, third-parties get the JavaScript library and web service support for developing in-browser representation of iCloud data.

Auto Layout 2.0 ✓

The new classes in Auto Layout are worth the version bump. Now we have all tools for supporting any screen sizes.

CoreData 2.0

There is nothing new but small improvements to the existing framework. Let‘s hope for 2016.

UXKit 1.0

This is not UXKit we expected, but we have much improved NSCollectionView and new NSStackView for building modern interfaces for the Desktop.

App Store 2.0

Nothing has changed in iTunes Connect. Nothing. MUSIC and Connect? This is developers conference, damn…

Objective-C 3.0

No new language, but we got some nice improvements like generics in collections for better cooperation with Swift.

TVKit 1.0

Indeed, they were ready to announce the new SDK, but something did not work. The most likely, we will see TV 2 in September along with a new iPhone 6S.

So, 7 out of 12. I‘m happy :) Have a great rest of the week!

June 5, 2015

WWDC 2015 Prospects

I have not yet met any articles on the subject from other developers. So here is my list of expectations and predictions for the new software and tools we may see next Monday:

Chance Product Details
200% iOS 9 You cannot keep the most selling mobile device in the world without yearly updates. An upcoming iPhone 6S must get new features, and adding them into iOS 8 is just a bad idea. So the new release of iOS 9 is unavoidable.
100% OS X 10.11 OS X is based on the same Foundation APIs as iOS, so even technically delaying the new version of Desktop OS sounds crazy. Sure thing, we will see the better and stronger Yosemity with a new name.
100% Xcode 7.0 The better WatchKit and probably TVKit are coming soon, so the next version of IDE may introduce new Instruments and Interface Builder. Also, I hope for improved refactoring tools and smarter CSV diff view for .xcodeproj files.
95% Swift 2.0 The new version of language would fix major problems with current implementation and also give it a huge Marketing push. The lack of updates and some hints from Cupertino make me almost sure that we will see an update.
80% WatchKit 2.0 3.500 Apps in the store is a lot, but this must be a joke for Cupertino. They need 350.000 and growing. After promise to release a native SDK, many developers are on hold, and new APIs should inspire them.
75% CoreData 2.0 Modern framework is perfect for Obj-C, but feels like a hack when you use it in Swift. Apple promotes cross-plarfom apps, but CoreData cannot work with CloudKit “natively”. So we definitely need a new solution for persistent storage.
70% CloudKit 2.0 The new platform for iCloud development announced last year is great, but it lacks such basic features as sharing data between accounts and managing it from Web. Let's hope for some improvements in the the Sync framework.
60% UXKit 1.0 The much discussed framework used to build UI in the new Apple Photos app sounds like a good replacement for “out-dated” AppKit. Deprecated NSCell, the new NSCollectionView, native toolbar navigation, tintColor for controls… Why not?
50% App Store 2.0 In-app reviews, developer replies, separate charts for games and apps, fixed search, native trials etc-etc. We heard so many fantastic ideas last year that it is a crime for Apple to not implement any of them.
25% Objective-C 3.0 Swift cannot replace ObjC with its runtime and nil-messaging. I believe both languages will co-exist like iOS and OS X borrowing all the best from each other. As result, we may see “modern” structs and enums or even generics in the newer version of Objective-C.
15% Auto Layout 2.0 This is just my wild guess as a solution for adaptive layouts that should work on all devices from tiny Apple Watch to the huge Apple TV. This is partially solved using size classes in iOS SDK, but they are not intuitive and hard to build and support in code.
5% TVKit 1.0 Recent rumors suggest that we will not see the new generation of Apple TV, but we have not seen Apple Watch after announcement as well. Developers need more time to adopt their apps for the huge screen, so why not give them tools in advance.

P. S. There is a follow-up blog post with results!

June 2, 2015

How to release a Mac app: 7. Marketing.

There is only thing I can advise regarding marketing: Build the best Landing Page.

No matter how you distribute the app, you want to build the Website for it. In other words, Google must know everything about your product, and customers should easily find the trusted source of information and support.

The most likely, the web page for selling an app will include the app title and description, some screenshots, the list of features, and cross-links to pages like Support, FAQ, Press, and Documentation. Maintaining a blog is a hard task, but if you are planning to release other apps in the future and stay in touch with the most loyal customers, you should definitely consider it.

The most important thing here is to design appearance only after the contents. First of all, make a SEO-friendly web page using best practices for accessibility. Only then make it great-looking and define styles with animations.

Also, it is usually a good idea to collect emails from users who are interested in getting news and other updates about the app and your future products.

Design and development is the easiest part. Promotion is the hardest one. Make sure to have a marketing plan before you release an app, because Launch is the time when you get attention and coverage for free. Use it wisely!

June 1, 2015

How to release a Mac app: 6. Distribution.

Once the app is tested and ready for launch, you have to implement a mechanism for making money of it. Be it the license generated on your own server, the yearly subscription, or In-App Purchase in the Mac App Store. These are two most popular ways which you may be interested in. Some professional apps implement both.

Custom Store

If you already configured Hockey and Sparkle for Beta distribution, then it is comparatively easy to add integration with a service like FastSpring to make money from the app. You have to implement safe storage for the license key as well and you are done.

If the app is expensive, you may want to implement some kind of Trial too. With FastSpring and license mechanism in place, this should not be a problem.

Also, there are companies like DevMate and Paddle which offer drop-in solutions which replace FastSpring, then take care of payment processing and provide useful analytics.

Mac App Store

Maybe your app is suited for Sandboxing, like 99% of all apps, and you don’t need a trial version. Then this distribution channel is a great option. Apple takes care of your builds and payments, and sure thing customers prefer to download apps “directly from Cupertino”.

However, there is a lot of work in iTunes Connect to be done. You should register the app, add metadata with pictures and descriptions in many languages, then configure the app for distribution using provisioning profile and certificate.

One more thing, the review and update process in the Mac App Store may become a nightmare, but in the end of the day, your app may be featured by Apple. Gotcha?

The last bit will be devoted to Marketing which I honestly have no clue about.

May 30, 2015

How to release a Mac app: 5. Beta Testing.

This part is short and actually can be skipped.

You may have a super-simple app which is ready for launch immediately after development. For more complicated apps, you would better to share them with Beta testers first. There are some options to consider.

Custom

In this case, you need a website or a landing page with cheap hosting for ZIP or DMG archives. For your help, there is a free component named Sparkle which can be used for periodic and automatic client updates. While distributing such Alpha or Beta versions, you would collect user feedback by email.

Hockey

There is also a great service named Hockey which enables you not only to distribute Beta-builds but also collect crash reports and user feedback. Additionally, you can use this service even after public release to fix the most annoying issues in the future updates.

Once beta testing is done and you are ready to ship 1.0, you need a distribution channel. See you after the weekend.

May 29, 2015

How to release a Mac app: 4. Development.

Needless to say, developers absolutely love to work on projects with completed workflow and visuals. You will get almost perfect estimate, if the prototype is alive and contains all graphics and states which should be programmed into the app.

When the product exists on paper, development will take less time. Still there are many things involved, including the following resource-consuming tasks:

  • Developer Program. Even if you plan to distribute the app without the Mac App Store, you need to have an official Apple Developer account which costs $100 per year. This allows to release an app signed by the Developer ID, which will be automatically permitted to launch on any Mac.

  • Coding. Creating a project, designing its architecture, configuring unit tests and coding in Xcode or AppCode may take a while depending on the project and release type. Fortunately, we have open source solutions: CocoaPods and Carthage save quite much time nowadays.

  • SVC. Source version control systems like git must be configured from the very beginning. Both the product owner and the developer should have access to the same project in GitHub or BitBucket. The good code base should have a well-maintained repository with full history to help teammates in the future.

  • Signing. Once you have become an Apple Developer, created a project in Xcode, and prepared your working environment, it is a good idea to configure signing using Apple certificates and try to launch the signed app in Release mode. Provisioning is not a cake, especially when your app is sandboxed.

  • Sandboxing. If your app is intended for the Mac App Store, it must be sandboxed. The thing is that Sandbox environment has limitations and influents on the architecture. You may need XPC for network operations or special permissions for integration with other apps in the system etc.

  • AppleScript. If your app is targeted for advanced users, consider AppleScript support. Mac apps do not provide this by default, so you may spend additional time and efforts.

  • iCloud. Apple Cloud is available only for Mac App Store apps. If you have an iPhone counterpart and want to provide Sync, or if there is no Mobile version, but you still want to provide Sync, add 35-45% to development costs. Proper sync implementation is very hard even if you choose Dropbox or Parse as a backend.

  • Undo. It is expected on Mac that any app should support Undo and Auto Save for Documents. This kind of development is not as hard as Sync, but still takes time. Make sure to support Undo and Redo from the very early releases, because adding it later will be more expensive.

  • Services. OS X has support for Services in contextual menus. For example, you can select a piece of text or an image and right-click it to see the list of available actions. You may consider to add such integration into your app to improve its usefulness for users.

  • Help. To make the best app, take care about all the tooltips, accessibility and contextual help buttons with references to the local Help Book. Testing and development will take more time, but this is what makes your app truly native on OS X.

Depending on a project, development takes 40-80% of time, and in fact it never ends because of Bug Fixing. In the next post we talk about Beta Testing.

May 27, 2015

How to release a Mac app: 3. Icons.

Yesterday, we learned something about preparing Design for the Mac app. Let's continue with icons!

For customers, the app icon is exactly the same thing as the program it represents. So Icon Design is extremely important, and you should plan for it separately from mockups and graphics. Do not forget about Retina Display support which requires even more work.

  • Dock. This icon will be displayed in Finder and on the Mac App Store page. But if you are lucky enough, it will live in the user Dock. So you should tend to make the best citizen which must look perfectly as in the Dock attached to the Bottom as to the Left or the Right screen side.

  • Documents. Some apps work with documents and files, so you may need to create one more full-featured icon similar to the Dock which should be distinguishable and scalable in Finder.

  • Preferences. OS X provides standard icons for General and Advanced preference panels, but you may want to provide custom ones. These icons are small and do not require 1024x1024-rendered versions.

  • Menu Bar. This tiny icon should look good in black and white colors on the black, blue and white backgrounds. Ideally, it should be a universal vector template in PDF format.

  • Outlines. Outline views may represent a tree or grouped data in the app eg. Sidebar became a standard control in master-detail interfaces. Some apps use monochrome icons here, other prefer bright and colored ones, so this is up to you.

  • Tables. Items in the table rarely need their own icons. Such lists can be massive, so repeating graphics may look not so nice.

  • Controls. Using custom graphics all over the place is nice for some kind of apps, but usually you should prefer Clarity and Deference. Try to use more white space and generate icons from the user-provided contents like photos, avatars, website icons etc.

That's it about interface and icon design. Tomorrow we'll dive into Cocoa Development!