CloudMine: Now With Swift


The recent unveiling of iOS 8 introduced a new programming language: Swift.

Many are wondering when their favorite services will support this innovative new language. For CloudMine, that time is now. With the new CloudMine Swift library, it’s easier than ever before to upload, download, and manage your data and access other CloudMine functionality.

To use our library in your Swift projects, import the header file into your project’s bridge header.

You can download our library here, or install it using CocoaPods. A bridge header is a file that allows a developer to use Objective-C libraries in her Swift code. Be sure to designate this header in the Swift Compiler section of project’s target. For a more complete discussion, see this StackOverflow answer.

Both Swift and CloudMine are based upon the principles of speed and simplicity. Here are some quick examples to get you up and running with CloudMine:

First, create a CloudMine object to facilitate the transfer of data:

This can be created wherever the object is needed.

In the past with Objective-C, this is how you would save an object:

To save an object with Swift you simply call the save method on your object:

Here’s a shorter version:

Object retrieval in Objective-C:

The same in Swift:

It’s as simple as that. In less than 10 lines of code you’re on your way to building better apps, more easily, with CloudMine. Send us an email at if you have any questions at all. We are always here to help.

Why Biomeme is Using CloudMine


This is a guest post by Maximilian Maksutovic, Biomeme’s software lead responsible for iOS, web, and Arudino development. Biomeme is a startup developing a smartphone attachment that can perform realtime DNA analysis, and is backed by Mark Cuban and Dreamit Ventures. Product systems will sell for around $2,000, but the company is hoping to bring it to drugstores around the world for around $200 in a few years’ time. Just a few applications include tracking diseases, testing food and water for pathogens, and serving as a detector for bioterror agents.

Being a relatively young developer, I am fortunate enough to work in an era of incredible tools: sophisticated IDEs, excellent compilers, and every sort of library and API imaginable. The one thing I am most thankful for is cloud-based backend systems. I can imagine some older, more stubborn developers would like to say that building and maintaining custom servers “builds character.” However, I also understand that most startups, including Biomeme, do not have the time or money to properly build these systems. In addition, these systems are often painfully overkill unless your startup is serving large amounts of users and data concurrently; which, let’s be honest, it isn’t.

My first introduction to cloud-based backends was Parse. I used it for my thesis software engineering project, where I built a self-guided tour for iOS of the Fairfield Osborne Preserve at Sonoma State University. The app consisted of a map with the trail of the preserve overlaid on it. As you would walk on the trail, the app would trigger certain geopoints that would attract the user to a specific cultural, geological, or ecological point of interest. The user would then be asked to look around their current position and be quizzed about certain features regarding the point of interest.

Using a cloud-based backend made this project feasible in a very short amount of time. It took only 4 weeks. I was able to capture geopoints for both the trail and points of interest. I could easily tag the data necessary for the internal database for the app. Using this system also allowed for my biology major collaborators to have a central place to upload additional content (the quiz questions, detailed narratives, additional photos/maps/scientific data/etc.) without the need for email attachments and USB drives.

Prior to graduation I was hired at Biomeme, an incredible startup that enables anyone to do mobile real-time DNA analysis on a smartphone. We had some initial talks about the data management that would be required: we would have to collect and store both experimental and patient data. We would need to configure, save, and share different tests. We must have been able to display data on different devices, porting it to the web, integrating with disease monitoring sites such as, HealthMap, and SAGES, as well as electronic health records. Working with such sensitive data, I knew HIPPA compliance was going to be an issue and needed to be addressed from the start. My main problem with Parse is that it had directly stated it is not HIPPA compliant, and hadn’t made any promises of being compliant in the future. Regardless, we were at such an early stage that I told the team we should use Parse to get off the ground. I was thinking that, by some miracle chance, I could address the HIPAA compliance with some other solution or subcontract someone to help me do it.

When I moved to Philadelphia to join the team, we were working out of VentureF0rth, a co-working space that also played home for CloudMine. I hadn’t heard of them, but after some introductions they told me they had an open source API that was similar to Parse’s. I was certainly interested, especially considering that they said the magic words of, “Oh, and we’re HIPPA compliant.” After building up their MVP to our first beta, it came time to start the data integration.

After a very clear and simple “getting started” guide and tutorial, I noticed one thing right away working with CloudMine: the API felt so natural to the iOS SDK, as if it was written by Apple engineers.

My biggest pet peeve with Parse was subclassing, let’s compare the difference: Parse Subclassing:

After setting up the class, you then have to “register” the subclass in your AppDelegate:

Now let’s compare how we would implement this ISCoordinate subclass in CloudMine:

So let me explain some of my resistance with Parse. For the subclass you need to add this class method +(NSString) parseClassName, which was needed for my purposes just to return a string. This certainly seems a little superfluous. Next, the class has to delegate to <PFSubclassing>, which seemed cryptic to begin with. If one looks under the hood to better understand this process, the result is even more incomprehensible. You also need @dynamic instance variables, which are not well explained. Finally, you are forced to create a Parse instance method which requires the following line: MySubclass object = [MySubclass object]. The [… object] message, again, seems rather cryptic; and again, looking under the hood is even less helpful.

With CloudMine, the code is standardly defined, using the default initWithCoder and encodeWithCoder methods. This is helpful because now all of your CMObjects are compliant with NSSerialization. With this, we can store all of our objects locally in case the user does not have an active Internet connection, and the app can continue to function without an active connection. Moreover, nothing about subclassing with CloudMine feels out of the ordinary; I feel completely at home making CMObjects just as I would NSObjects. A good API written for a specific platform should feel completely native to the parent language, and I feel that CloudMine does perfectly.

Now, some developers reading this are thinking “Big deal. Every API has its quirks. Every language has its quirks. We just have to grunt, bear it and learn it.” Do you want to work with an API that forces its own architecture down your throat and requires a workaround from the developer, or do you want an API that works hard to conform to the language you are working with? I prefer the latter.

To drive the issue further, lets talk about business. Every choice of language, platform, and API has a direct business cost, especially for a small startup. A quick example: Biomeme’s app needs chart functionality, which a previous developer quoted nearly $20,000 plus many months to implement. I looked at the (free) Core Plot API and thought it was feasible, but to make it look pretty and perform well it would take a large chunk of time we just didn’t have. I decided to get a ShinobiCharts license (which was $400), however I had a beautiful Biomeme branded chart running in less than 3 hours. Should have I used a free API? Maybe. Would the extra time learning and the API to deliver a half-baked product been a good decision for Biomeme? Definitely not. The same goes for our cloud backend. Wouldn’t it be an amazing, fun project to build a HIPPA compliant backend hooked up to a Rackspace server, shuttle data in and out using Ruby or Python scripts, and encrypt and isolate the data with OpenSSL? Definitely! Would the massive time sink to do that, —plus the bug hunting, —plus writing the necessary documentation for other recently on-boarded developers be a good decision for Biomeme? Definitely not! All that time I would of taken to build such a solution would take me away from building core functionality of the Biomeme App, delay the ability to demo the system to customers, and delay our chances of making it as a startup.

By using CloudMine, I was able to deliver a brilliant product with all the necessary data being stored and retrieved from the app, hassle free. Better yet, all of the code and architecture I have currently written is completely future-proof for when we want to extend this data to web apps and other platforms such as Android. Best still, once we require HIPPA compliance, all CloudMine has to do (in the words of co-founder Ilya Braude) is “flip a switch” and we are fully compliant. I recently brought on a contractor for some work and he helped augment some data management within the app, and immediately fell in love with the ease of CloudMine’s API. Within a weekend, we had created a perfect, elegant, future-proof solution for shuttling data back to CloudMine, even in scenarios where there is no active Internet connection.

Of course I could have done all of this with Parse. Despite my minor problems, it is a fine API and used fairly extensively across the development world. But without HIPPA compliance and the lack of personal support, the platform falls flat for me. CloudMine is a company that I feel partners with you to help bring your product to a higher level. The level of support that CloudMine provides is second to none, and that is worth every expense of the platform. If I were to receive strange messages or if code seemed to not work right with the API, I could contact CloudMine and within a few hours have a detailed response, complete with code examples.

All in all, I chose CloudMine because I want a system that simply works. I want a system that allows me to write native Objective-C, perform tasks asynchronously, subclass to my heart’s content, and to be future-proof for things like HIPPA compliance. And most importantly, I want a system that has the incredible support CloudMine offers.

Business Continuity


StackMob, a mobile backend infrastructure company, recently shook the industry by announcing that they are shutting down their service after being acquired by PayPal several months ago. While significant speculation surrounds the situation, there are many customers seeking alternative backend solutions to power their mobile applications. StackMob has offered a CSV data exporter, allowing customers to extract their application data and continue development either on their own, or with the help of other backend providers.

In response to increasing requests, CloudMine has created a CSV/JSON importer to help ease transitions for those who enjoy the many benefits of a cloud-based backend platform. We understand that the migration of mission critical applications is not simply a matter of importing data, so our team is prepared to work closely with you to understand exact requirements, offer objective advice and insight, and help guide you towards your best path to success — even if our platform is not the final destination of your application.

As a long-standing enterprise mobility company we understand the business continuity concerns expressed about the future of BaaS providers. To address these concerns, CloudMine assures both our current and future customers that, in addition to you always owning your data, applications will always have the backend infrastructure they need due to the platform’s portability and flexibility to reside in any environment, in the cloud or on-premise.

If you would like to explore a conversation with CloudMine, please send an inquiry to and our team will be in touch. It would be a pleasure to build new relationships with you and we look forward to supporting your mobile development needs.

An Alternative to Hiring Full-Time Engineers


Imagine you sign a new client project after giving an estimated delivery of 9 months. Congratulations! But wait — you’re already at capacity and have spent the past two weeks fighting off the major scope creep your new client is stacking onto your shoulders. The stress is piling up and you consider hiring new engineers, but haven’t found a match during your preliminary search.

You know this project is somewhat like a first date, and that if you exceed expectations you’re likely to be offered a waterfall of groundbreaking work — but here you are with no idea how to deliver!

Just when you thought there was no hope at all, we’re here to tell you otherwise.

What if you could take this 9 month project and have it shipped and delivered in less than a third of the time, without having to go through the exhaustive process of hiring new developers?

From the onset, this is a difficult topic to approach. However, it’s something that comes up in our daily lives as we grow CloudMine into a leading technology solution for agencies and enterprises. We’ve talked with agencies employing teams of engineers all scrambling to get their projects out the door. One agency was so strapped for development bandwidth that it had PHP developers writing Objective-C, HTML/CSS developers cutting their teeth on Node, and iPhone developers building Android interfaces. While it’s great to have a team that tackles any problem thrown their way, we can’t help but note that there must be a better, more efficient, less stressful way.

We’ve also had several conversations with prospective partners who are looking to expand their engineering team, specifically by hiring one or two back-end engineers to help maintain large multitudes of server-side stacks that have been cobbled together over the years. While this is the way business has traditionally been done — hire when you want to grow — we’re here to tell you there is a new, technological solution to your problem. First, however, let’s take a moment to run down some bullet points on traditional hiring and on-boarding processes and how they may stack up against a Backend-as-a-Service solution.

  • Hiring Process
    We’ve learned this takes an average of 6-10 weeks (per engineer) and a tremendous amount of time, energy and effort from many members of the current team. Additionally, hiring is often responsible for delaying engineering progress. Sourcing candidates, first-round phone interviews, face-to-face meetings, offers, negotiations and finally, acceptance — this is a long arduous process to endure for each new hire especially when in the middle of crunch-time.

  • On-boarding, Training & Ramp Up Time
    On-boarding can take, on average, 3-4 months. What will your new hire be responsible for? How will she blend with an existing team? Who’s going to take time out of their workday to train the new employee and bring her up to speed on current projects? How long does it take for a new engineer to become comfortable in her new environment, with her new project and her new mission? This last piece varies greatly person to person.

  • Salary, Benefits & Equipment
    It’s a known fact that full time employees cost significantly more than pure salary expenditure. Taxes, healthcare, 401k accounts and other benefits eat up a lot of these costs. Additional expenses like equipment, office space, digital services and more are also all rolled up in the total cost of a full time employee (Source). For example, here in Philadelphia it costs around $123,500 per year to employ a single full-time senior engineer. And in San Francisco, it’s even worse: it can cost upwards of $161,200 (or higher, where competition is fierce) per year.

  • Actual Development Time, Labor & Costs
    Once your new team member is hired and brought up to speed it’s time to actually start digging into the task at hand. This will include writing code, creating or expanding technical architecture to meet the company’s ever-changing needs, and making sure everything is working all the time. Maintenance is perhaps the largest nuisance of all. Servers have to have OS and security patches applied, firewall rules monitored, performance tweaked and re-tweak, and software tested and deployed. And when those servers crash, your employees are pulled off of their primary objectives and sent into crisis mode to discover and fix whatever went wrong. All of this costs significant time and money that would be better allocated to improve the product in ways that more directly affect the end user.

  • Risks of Hiring the Wrong Person
    Hiring mistakes are often considered the biggest expense a company can face, but these expenses are more than just monetary. Bad hires suck energy from companies and breed distraction, process disruption, and can have strong negative impacts on both company’s morale and overall productivity. If done properly, a good hiring manager will know how to choose the right person for the right position; but bad hires happen quite frequently, and as a leader you’ll need to be prepared for the fallout. According to one source, one bad hire could cost a company two and a half times their annual salary, turning a $100,000 salary into a $250,000 expense. Crazy! (Source)

There is another way

When you make the choice to step away from all this nonsense you’ll find that there’s a much better option. One that doesn’t require seeking out talent, crossing your fingers that there’s a culture fit, waiting for ramp-up, dealing with churn, managing any other unforeseen difficulties thrown your way, and then finally hoping the product gets delivered on time.

By leveraging CloudMine’s solution and expertise, you and your company are free to create what makes you and your product unique without needing to scale your back-end engineering team. Gone are the days of breaking your back to provide your customers with the data they need on the device they want. Simply plug existing data sources into CloudMine and your information is immediately available to be accessed by any endpoint imaginable: mobile apps, APIs, wearable computers, smart watches— the list is endless.

Any device. Any information.

Let CloudMine be your entire back-end and data integration suite, ready to go out of the box. Say goodbye to sourcing resumes, awkward interviews and “hoping the newbie works out”, and say hello to a new world of product-oriented bliss.

Come talk with us to see how we can help.

About Us