November 14, 2018

I’m switching to the NativeConnect Blog

Hi stranger, this is a quick status update if you don’t follow me in Twitter.

Recent years I was part of a team working on a nice AdHoc Task Management app named Cirkus. While I was a Mac developer in a company, we discussed a lot of topics and ideas with my fantastic Cocoa team. This was exciting experience, but I did not have any motivation to share something new in my personal blog.

In October 2018 I started a new project though. The native Mac app that I’m working on is named NativeConnect, and I’m really passionate about its technology stack. As result, I finally published something new about things like workflow automation and Swift Package Manager.

I truly enjoy writing for the NativeConnect Blog and have plans to post more AppKit and SwiftPM related stuff there. Thanks a lot for still visiting and reading my posts here, but I really hope to see you there!

P. S. This blog will still be named “iOS and OS X Development” 😄

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.


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.


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.