Building on-premise iOS/macOS build and test infrastructure in four steps

Anka Build controller is the management engine for your macOS private cloud. It presents a single entry point, through its REST APIs, for external systems to provision macOS VMs on a cluster of mac hardware (Anka Build nodes) from a specific version of a VM template pulled from Anka registry, for each run.

It eliminates the need to implement custom modules to address issues like reverting a VM to the snapshot, automated assignment of IPs, multiple request management through queuing, cleanup and other management tasks.

Pulling a VM template from the Anka registry for on-demand provisioning also eliminates the need to bootstrap the VM at runtime and enables instantaneous execution of tests. You might still need to do some incremental bootstrapping to pull latest build etc, but the initiation time is significantly reduced.

Watch Anka Build in action in this brief video – Demo Video

Let’s take a look at how you will set it up.

Step 1 – Deploy Anka Registry in a docker container. Installing Registry section in

Step 2 – Deploy Anka controller in a docker container and configure it. Installing Controller section in

Step 3 – Deploy Anka Build application package on all the mac machines where you want to run your VMs. Then, join them to the controller build cluster. These machines are now Anka build nodes.

Step 4 – Create the Anka VM templates that will serve as your iOS or macOS build or test environments. Load all your dependencies in this VMs. Then, push it to Anka registry. If your dependencies change, you can pull this VM from the registry, update it and then push it back with a different version/tag.

Your private macOS cloud infrastructure is now ready.

Use the Anka Controller REST APIs to provision environments or if you use Jenkins, deploy the Jenkins plugin.


Jenkins Plugin –

Developing iOS applications in consistent local environments

Is iOS developer productivity suffering in your organization? Let’s take a scenario of a company with more than one iOS developer working on different iOS projects. In such a setting developers tend to have issues running builds on CI, only to have it pass in their local environment. These types of failures during integrated build and test significantly impact developer productivity. When you dig into these issues, it’s very often because of incorrect global dependency linking, different library versions, incorrect or missing environment variables, or simply that their system is not set up with consistency.

While in theory, it’s possible to sanitize and standardize a developer’s machine, in practice, it’s almost impossible. Developers will always download new libraries and update versions of other tools to accelerate development, sometimes creating conflict with your build tools. Similarly, when iOS developers pull the latest source for development and build it on their systems, they face local build and test failures due to incompatibilities in the configuration of their dev environment. This problem is even bigger when iOS developers are simultaneously working on multiple projects.

Anka Run technology is built to address this issue. It brings the container-based development workflow to the iOS and macOS development world. Until now, it was not possible to package an iOS development environment in a container-like entity and distribute it to your team. Anka Run enables you to do this.

There are two modules in Anka Run. Anka Run for macOS and Anka Registry. Anka Run for macOS is a very lightweight engine with a footprint of 15MB, to create and run macOS VMs. Anka Registry is a repository where these iOS or macOS dev environment VMs are managed and can be pulled to each developer machine, creating a consistent developer experience everyone can use.

First, Anka Run is deployed on all iOS developer machines, and Anka Registry is set up in a docker container. After initial installation is complete, devOps engineers and/or developers can create fully self-contained iOS development environments with all dependencies in an “Anka VM”. This Anka VM is then versioned and pushed to Anka registry.

Next, developers continue to work in their native Xcode IDE or another environment. They pull the respective Anka VM corresponding to multiple projects and configurations on their machine and use them to execute local build and unit tests. With the ‘anka run’ command developers work from their local command line interface to execute builds and tests inside the Anka VMs.

The end result is that iOS developers are always building and testing against a common set of dependencies and linkages, without the need to set these on their machines. Simply put, Anka enables an agile and developer-centric approach.

Watch this video to see all Anka Run components in action.

Setup macOS 10.13 beta High Sierra environment in an isolated VM

This week Apple announced developer beta availability of the new macOS version 10.13, High Sierra and, we started investigating support for this in Anka. We are excited to share that now you can create isolated dev/test environment with this version in an Anka VM.

Our developers have discovered that this macOS beta version prevents auto install/load of third party signed drivers. These drivers need to be explicitly enabled by the users. Hence, just using Anka auto install method to create VM is not enough. After creating the VM, you will need to do additional setup to enable Anka PV drivers.

Following are the setup steps

Step 1 – Download and install Anka Beta from

Step 2 – Download ‘Install macOS 10.13’ from your developer account.

Step 3 – Use Anka auto install method to create High Sierra VM. Type following in command line.
anka create-disk --size 40G --app ~/Desktop/Install\ macOS\ 10.13\

Step 4 – After successful execution of step 4, execute ‘anka create’.
disk created successfully at: diskid.ank
anka create --image-id diskid --ram-size 2G --cpu-count 2 hisierra

Step 5 – Type ‘anka view hisierra’ and complete the remaining macOS setup steps.

Step 6 – Go to system preferences and then go to Security and Privacy and allow extension by Veertu Inc.

Step 7 – Stop and start the VM.

Step 8 – Run the following from a terminal inside the VM.
cd /Library/Filesystems/osxfuse.fs/Contents/Extensions
sudo ln -ls 10.9 10.13
Step 9 – Stop and start the VM.

Step 10 – Go to the VM window
anka view hisierra
Step 11 – Go to system preferences and then go to Security and Privacy and allow osxfuse extension by ‘Benjamin Fleischer’. We use third party osxfuse for shared FS feature.

Step 12 – Stop and restart the VM.

Step 13 – Verify the setup. From your mac/host, execute the following command.
anka run hisierra ls -l
If it displays the contents of your current mac folder, then your VM is fully configured with all Anka PV drivers, guest add-ons and ready to use.

Anka Public Beta

As the WWDC conference gets underway with exciting new updates for macOS, iOS developers, we are thrilled to announce the availability of the beta version of Anka. For the past few months, we have been working with private beta users of Anka and are extremely grateful for all the feedback we received, which helped us shape Anka.

Anka is now available as ‘Anka Run’ and ‘Anka Build’ beta products. Anka Run can be used by iOS and macOS developers to create and consume reproducible development environments on their dev machines. Anka Run will enable developers working on the same project, to build and test their code changes against the same set of external libraries, configuration, toolchain and environment variables. This will significantly increase developer productivity. Check out technology page for additional technical details.

Anka Build can be used by infrastructure admins to very quickly build a private cloud on Apple hardware and provision on-demand instances of their environments from preconfigured VM templates. Anka Build is an all-in-one solution to virtualize macOS, manage macOS VM templates and provision them on-demand for CI jobs. It removes the setup complexities associated with existing approaches while providing a fast-performing and responsive macOS private cloud. Check out technology page for additional details. Anka Run and Anka Build, when used together can significantly accelerate the velocity of macOS and iOS development.

How to Get Started with Anka

UPDATE – High Sierra macOS 10.13 beta is out and Anka supports it. Download developer beta version ‘.app’ and work with it inside an Anka VM. Here are the setup instructions.

There are multiple ways to get started with Anka. Start with first downloading and installing Anka Run beta. Download and install the Anka Run application package on a few developer machines. Setup Anka registry in a docker container using the dockerfile included in the Anka-registry package. Then, create macOS Anka VM on one of the mac machines running Anka Run application and configure that VM with your project dependencies. Push that VM to Anka registry. Then, ask your developers to pull it on their machines(running Anka Run) and use them for local build and tests.

Then, move on to configuring a private macOS cloud for your CI. Download and install the Anka Build application package on your macOS CI machines. Setup Anka Controller in a docker container using the dockerfile included in the Anka-controller package. Register Anka Build nodes to Anka Controller cloud, configure the controller to talk to the previously installed Anka registry and you have a private macOS build and test cloud!

Additionally, if you use Jenkins for your CI, then install the Anka Jenkins plugin on your Jenkins master server to run your jobs on Anka cloud. Send us your feedback and questions at, share insights on your setup with others at @veertu_labs, and help us spread the word.

Introducing Anka

Today, Veertu Labs is thrilled to pull back the curtain on three Anka toolsets, our latest endeavors geared towards making macOS and iOS development infrastructure management simple and streamlined. Anka technology is a suite of three products that are built to bring the experience of working with containers to the complex macOS/iOS development process. We are inviting all macOS/iOS developers and as well as DevOps engineers to give Anka a try by joining our trial program ( We’ll provide launch dates and general availability of these solutions soon as well.  

It’s no secret that container-based app development and deployment has significantly changed the landscape of developer operations. Why a container approach? Because containers are built to be extremely lightweight, easy to interact with and extremely portable. While macOS cannot yet be run inside a container,  (different than running Linux and windows containers on macOS), we have taken the concepts of container-based devops to iOS/macOS development with Anka.  

Anka’s core hypervisor technology enables creation and execution of extremely lightweight and responsive macOS VMs on Apple hardware. The performance of build and test operations is extremely critical in using virtual environments successfully. As such we developed proprietary paravirtual network and block drivers in our hypervisor for macOS VMs. Then, we built a container ecosystem around Anka, so developers and systems engineers can effectively work with it for iOS and macOS development.  

A Container Ecosystem

We built the container ecosystem with three components: Anka Build, Anka DevOps, and Anka Device. Anka Build enables systems engineers and developers to build an on-premise macOS private cloud on Apple hardware. Anka Build consists of Anka’s native virtualization technology, as well as the Anka Registry and Controller services for storing and managing the on-premise macOS private cloud.  Anka Build enables familiar workflows used with many large cloud providers by allowing you to create version-tagged macOS VMs and store them in the Anka Registry. With Anka Controller’s REST API, you can use stored VMs in Anka Registry to spin up fresh, isolated copies for development, build, or test.  

Anka DevOps is a combination of Anka Registry and the Anka client. Anka Registry stores your macOS virtual machines with proper versioning and optional tagging. Anka client is a lightweight program that runs on your developer machines, that can pull relevant build VMs and make them available for local, but managed development.  

Anka Device extends Anka Build and Anka DevOps to allow iOS on-device testing within the macOS private cloud. Plug in any iOS device to Apple hardware running the Anka Build or Anka DevOps toolset to make real iOS devices available for your iOS CI system or to individual developers on-demand; Anka Device allows for the setup and management of the devices centrally in a private device cloud.  

Anka Build, Anka Devops and Anka Device are the building blocks we think will completely transform infrastructure management for macOS or iOS development.

The pace of growth of iOS app development is astounding and at the same time, the complexity and capabilities of these apps, both B2C and B2B are also increasing significantly. The iOS development methodologies have to stay ahead of the curve to make life easy for developers and publishers.

Listening, Growing and Adapting

It’s been nine months since we launched Veertu Native, the first version of our native MacOS virtualization platform based on Apple’s Hypervisor.framework. In these nine months, Veertu Native has seen significant adoption, and we are learning a lot from our users. We are also growing as a company. We expanded our development team with excellent developers, who are equally passionate about development on MacOS.

We have been busy in the past couple of months prioritizing user feedback, developing features and now we are ready to announce them.

This product release addresses some of the key items from the user feedback. It includes support for bridged networking and USB Pass Through and is now available as Veertu Desktop download outside the AppStore on our website. While we are very excited about being able to continue development on Veertu Desktop, we are also sad about taking this application out of the App Store. We explored various methods to make these new features work with sandboxing restrictions of the App Store, but it seems that this is not possible. So, we had to remove Veertu Native and Veertu Business from the AppStore.

Veertu Desktop leverages privilege separation model. It uses privileged resources only on demand basis for when you enable bridged networking support.

Our existing users can choose to continue to use the version they have installed, or they can switch to Veertu Desktop version. We have implemented capability in Veertu Desktop to migrate existing VMs from Veertu Native to Veertu Desktop, during the install process.

Being part of Mac App Store has great benefits, and we hope to be back in there as soon as possible.

We are also excited about one more thing. We are making Veertu Desktop Open source. It will be available on and will continue to be developed and maintained. We have also been working on innovative technology in the area of increasing velocity of application development on MacOS, iOS, and other Apple mobile platforms. Stay tuned for more updates on our Twitter channel and keep sending us your feedback.

Virtualization of macOS Sierra public beta

New versions of operating systems often cause a lot of heartache for Infrastructure technologies that run on top of them. As an example, virtualization products are often tied tightly with the underlying OS and supporting newer versions of that OS is never straight forward. Not at Veertu, though.

We started seeing feedback on our twitter channel from users, who were trying to run Veertu on the macOS Sierra public beta and run into issues. This got escalated to our developers and within a very short amount of time, they had identified the root cause and implemented the fix in the codebase. The new version with the fix was then pushed to Apple Store for review and publish.

As I thought about it more, I was really intrigued that how we were able to so quickly support the new macOS Sierra, while other similar solutions were/are still proposing all sorts of workarounds on this.

In fact, I later discovered that the code change that we had to implement, was not even done specific to supporting Sierra. The code change was to fix something that was implemented incorrectly from the very beginning. So, we basically, had to make zero code changes to support macOS Sierra.

This is because system driver APIs often change as Operating System vendors come out with new releases and this often breaks the kernel extensions based tool ecosystem that’s built on top of that. It’s different with Veertu. Veertu is built on top of the hypervisor.framework in user space, which abstracts the underlying macOS dependencies and presents simplified and standard interface. So, while macOS Sierra is a new OS release, the hypervisor.framework interface is still kept the same(maybe even extended to include/expose additional features) and as a result, Veertu works for macOS Sierra with no changes.
Veertu on macOS Sierra

Veertu on macOS Sierra

Cross browser testing on Mac

In one of my earlier blogs, I discussed how Macs were becoming the workstation of choice for the developers. In this blog, I want to look at how developers, who are working on browser based applications can leverage native virtualization solution like Veertu running on OS X/Mac to execute cross browser testing across different operating system versions. Take the example of unit testing your app on different versions of IE supported on different windows versions. While it’s kind of difficult to get multiple versions of windows to build test environments(unless you have MSDN account ), I came across this very interesting resource by Microsoft – Microsoft has packaged IE versions + Windows version as VMs and made them available for testing purposes. If you are running Veertu on your Mac, you will start by downloading VMs in either Virtual box, Fusion or Parallels format. I downloaded Virtualbox VMs of IE8 on Win7, IE10 on Win7 and the new IE MDEdge on Win 10. After unzipping the files, I imported these VM images into Veertu. I was able to start the VMs in Veertu right away without any manual intervention.IE 8 on Win 7 VM on Veertu cross browser testing on Mac  

Cross Browser testing of Web Apps

I am using YouTube web app to demonstrate the cross browser testing on these VMs running in Veertu. One of the advantages of using the Hypervisor.Framework, is that even with all of these 3 VMs running on top of Veertu(I am using Macbook Pro with 8GB RAM), it doesn’t seem like the Mac is resource constrained. The footprint of Veertu itself is extremely small, just 13MB. Linux Windows OS X VMs on Veertu cross browser testing on Mac   Here YouTube app in IE8 on Win 7 VM is reporting an error that it’s no longer supported on this IE version. VM in Veertu on Mac cross browser testing on Mac The App on IE 10 on Win 7 is reporting that the support for this IE version will be deprecating soon. IE 10 on Win 7 Veertu VM old browser version warning cross browser testing on Mac And, here is the new IE version MSEdge(stable version) on windows 10 VM on Mac in Veertu. MSEdge windows 10 VM in Veertu cross browser testing on Mac This is one use case example of the need to run virtualization solution on Mac. Other include running Linux dev environments, malware testing VMs etc. In the upcoming Veertu updates, there will be support to run OS X VMs. This will open up a broad area of iOS build and test on your Mac, with multiple OS X VM capsules running specific Xcode and iOS Simulator versions. Stay tuned.

Uncovering OS X Hypervisor.Framework – Part 1

We mentioned in our previous blog that we had been working with hypervisors and most recently with Apple Hypervisor.Framework since it’s release last year. We have used Hypervisor.Framework to develop light weight, high performance and highly reliable virtualization for OS X. With the recent attention and focus on this framework, we thought it would be good to share more detailed information on this with our users. First, a little bit of history on virtualization for Mac. While the hardware of a Mac is produced solely by Apple, it does use certain standard components like Intel x86-64 processors. x86 processor architecture uses the concept of privilege levels (or privilege rings) for machine instructions. The most privileged operations, which are reserved for the host operating system, have a privilege level of 0. A virtual system running on top of the host can’t access the 0 privilege level directly. So, Virtualization technology(VT) extension to CPU, memory and I/O hardware were developed as a technique to overcome this challenge. There are also software based approaches to address this – binary translation and paravirtualization. But, they have some challenges around ring aliasing, address-space compression, and non-faulting access to privileged processor state. Intel’s VT-x virtualization extensions, VT-i extensions and AMD’s AMD-V technology were released to enable hardware assist virtualization. Now, in order to use the VT extensions, hardware-assisted virtualization engines (hypervisor) were developed as kernel extensions(KEXTs) on the Mac. In this model, the hypervisor has complete control over hardware, memory and operates in VMX root mode. It prepares a special Virtual Machine Control Structure (VMCS), which sets the state of the guest. The VMCS stores copies of guest system registers and also includes control bits that specify conditions under which the host will trap (exit) into the hypervisor. Once the VMCS is ready, the hypervisor executes VMLAUNCH and lets the OS take control. The OS runs in VMX non-root mode (guest mode). When any of the exit conditions (privileged instructions) that were specified in the VMCS are met, the processor VM Exits into the hypervisor mode. After execution of the privileged instruction, the hypervisor executes VM Entry instructions, returning to the VMX non-root mode. Because, these hardware assist hypervisors are implemented as kernel extensions for Mac, there are some known issues identified with this approach. Any bug in KEXTs (kernel extensions) can have severe consequence than bugs in user-level code and could cause a kernel-panic, crashing the operating system. In some implementations, KEXTs close interrupts, so, which can have a negative impact on the responsiveness of the system. Kernel resources are wired(permanently resident in memory) and thus are more costly to use than resources in user space task of equivalent functionality. There are also no safeguards in place inside the kernel. For example, a memory leak inside a kernel will result in loss of this memory until the next reboot of the system. With OS X v10.10, Apple introduced the Hypervisor.Framework, which allows virtualization to be implemented on top of OS X, without needing to deploy third-party kernel extensions (KEXTs). It exposes Intel-VT extensions through APIs, to be run in the user space and eliminates the need to run third party developed virtualization code directly in the OS X kernel. At the command execution level it looks something like this. Hypervisor.Framework guest execution: Userspace:
  1. Getting VMCS ready – Veertu code
  2. Execute hv_vcpu_run() – Veertu code
Kernel space:
  1. Hypervisor framework validates VMCS – Apple code
  2. Hypervisor framework execute VMLAUNCH – Apple code
  3. Hypervisor framework wait for VMEXIT – Apple code
  1. Analyze VMEXIT and get back to step 1 – Veertu code
Now, this approach addresses most of the KEXT based implementations issues. A large portion of OS X virtualization code (dealing with VMEXIT etc.) executes in the user space. If there is a bug, it only impacts this application and the application can be closed without impacting other apps or the OS. Any memory leak type situations are handled by the OS X kernel in a safe manner. The decision to close system interrupts is done natively by Apple as per the OS X scheduling policy. What we have shared with you in this blog are additional details based on our experience working with this Hypervisor.Framework. Veertu implementation has lot more details and is much more extensive with guest add-ons etc. In the upcoming months, we plan to share additional details with you on our implementation. Do share your feedback with us.

The March towards adoption of OS X Hypervisor.Framework for Native Virtualization capabilities

Today, Docker announced beta availability of Docker for Mac, built on top of xhyve, one of the derivatives of OS X Hypervisor.Framework. This demonstrates two things – OS X recently released Hypervisor.Framework is a better architecture for developing virtualization on top of OS X, as opposed to installing layers of virtualization products. As a quick reminder, the docker machine was based on VirtualBox and required users to set VirtualBox on their Macs to be able to use the Docker ToolBox. A quick google search will reveal that this approach had a lot of stability and reliability issues. The second point, this announcement reveals is the growing importance of mac as the development desktop for developers. We, at Veertu, have been at work using the OS X Hypervisor.Framework for more than nine months. From the very beginning, we saw the advantages of using this to provide a native virtualization experience on mac. It’s great to see others follow the same path, and all put together will lead to more rapid awareness and adoption of native virtualization for OS X as well as Apple adding more useful features like bridge networking and USB support to the Hypervisor.Framework.