Author: David Ng

Swift3: Uploading Image with Serverless Platform Skygear

This tutorial is written for Skygear, a backend-as-a-service (BaaS) that helps you build serverless apps. Skygear includes features such as push notifications, cloud database, and user authentication.

Go Serverless

Almost any app these days has a photo uploading feature. Whether it’s a social app or a review platform, a photo uploading feature is essential for gathering user-generated content. A feature like this shouldn’t take a whole day to write. Here’s a walkthrough for you to develop a simple app that allows you to upload images and share them using Skygear.

As mentioned, Skygear is a serverless platform for building apps. One of the features, Skygear CloudDB, enables you to upload your user-generated content  to the cloud storage. This content can be  images, videos, or even audio files. The files will be hosted in the cloud and made available for your mobile app clients. You can download the Swift photo feed demo and run on Xcode to see how photo upload works.

Setup your Skygear backend

First thing, in this example, you have to initialize Skygear before any Skygear app reference is created or used. If you have already done this for another Skygear feature, you can skip this step.

Initialize Skygear:

  1. Create your app backend on Skygear Portal (2 mins)
  2. Install the Skygear SDK (10 mins)
  3. Import SKYKit module & other configuration into your code (3 mins)

You can follow  this step-by-step iOS guide to initialize Skygear.

Uploading a photo

Ok. Let’s start implementing the uploading photos feature. In Skygear, you can make use of Asset to store file references, such as images and videos on the database. Let’s say, your user has taken a photo. In order to have the photo uploaded, we will call the uploadAsset API to upload the photo image file as an asset.

In the above sample code, we define an uploadable SKYAsset and set the chosen image data as the asset data. We also set the mimeType of the asset as image/jpg. Upon calling uploadAssest, the asset assigned will be uploaded. Then we pass to the completionHandler to handle success / fail upload case.

You can check the full list of supported mime types here

Saving the asset with a photo record

Since we want to query the photo later, we have to save the image to the cloud database.
In Skygear, an asset can only be saved with a record but not as a standalone upload. We will create a photo record and assign the uploaded asset as asset of the record.

Fetching the uploaded photos

Now, we want to load back the photos we’ve uploaded through the app.

To access the photos, we need to query the photo records. We can directly access the uploaded asset with SKYAsset.url .

As a result, we have imageAsset.url in hand , so we can load back the image and display it on any device.

To learn more about Skygear
In addition to images, you can also upload other file types (such as voice messages, PDF files, live recordings, etc) to the serverless platform. Please see detailed documentation about file uploading here: Skygear iOS Assets (File Upload). If you need my support on trying it out, just ping me (David) on Skygear Google Group.

Tell us what you think and subscribe to our blog for more project updates!

Follow us on Twitter to get updates.

You’ve been working hard preparing for your launch to AppStore. The final step is getting it submitted to iTunesConnect.


You have to fill in the app details, upload the app icon, localized descriptions and preview imagesupload them one-by-one going through your list of localizations for each supported device in English; one-by-one for each device in French; one-by-one for each device in German, etc, etc.
OK, 13 languages.

You have to upload screenshots one-by-one for each device, for each locale. Oh that’s O(n²)

Let’s say you have built an awesome app for iPhone & iPad and now it’s ready for launch.

Question, how many preview images exactly do you have to add?

The answer is simple. For each locale, there are 3.5-inch, 4-inch, 4.7-inch, 5.5-inch and iPad screenshots (and don’t forget the upcoming iPad Pro). There are 5 images in each set, that gives you 5 x 5 = 25 pcs for each locale.

Needless to say, you will have to organize 25 x 13 = 325 preview images to iTunesConnect. Sounds scary right?

Continue reading

Spentable (Expense Tracker): How we built our first app for watchOS 2

In WWDC2015, Apple announced iOS 9 for iPhone and watchOS 2 for iWatch. It has been a huge revamp for watchOS. Not until now, a watch app finally runs natively on the watch.

That means the code is now executing on your watch instead of the phone. By reducing multiple times of data transfer between devices, this is going to make the app loads a lot quicker and responds in a shorter period of waiting time.

watchOS 1
WatchKit Extension runs on the phone and the Watch App is more like a display console for your app.

watchOS 1

watchOS 1

watchOS 2
WatchKit Extension now runs on the watch, you don’t have to run a watch app with the phone connected actively.

watchOS 2

watchOS 2

 Spentable: our first app on the watch

Spentable Watch FaceOursky has recently built Spentable 2.0 , it’s also available on the Apple Watch.

Spentable is a handy, in-your-pocket app that helps you to track your expenses and make purchasing decisions. Now you can even track you daily expense via the watch App without taking out your phone.

In this post, we will talk about the experience on building an app for watchOS 2.

Since the watch app is now running on the watch as a native extension, there are situation we need to handle data sync between the phone and the watch. For example, we wish expense input via the watch will be reflected on the phone instantly.


Get connected to the phone: Watch Connectivity Framework

In watchOS 1, the watch app must be connected to the iPhone app (we call it the main app) to work. We often call [openParentApplication:reply:] to send a message to the iPhone app. However, now the connections in watchOS2 are handled by the Watch Connectivity Framework.

The Watch Connectivity Framework provides a seamless background connection between iPhone and iWatch. It helps doing all the synchronization work between the main app and the watch app. When the watch app handles a user input say, a new expense item, it has to notify the main app and get the record updated. The could be easily done via the Watch Connectivity Framework.

This allows Device-to-device communication more freely (such as transferring files, user infos and application context around ). There are serval APIs to transfer particular data for different use cases.

So how do we choose between them?

Continue reading

Basic Open Graph techniques that optimize shared links on Facebook

Open Graph is a good standard, it helps turning a web page to become a rich object in a social graph.
If you follow the Open Graph protocol, most of the social platforms (Facebook, Reddit, etc. ) will crawl your website and present it in a nice and structured format.

A minimal open graph set-up requires these 4 tags:

  • og:title
  • og:type
  • og:url
  • og:image

To start with, implement Open Graph Tags as the followings:

Further optimizing the related Open Graph tags would be an advanced SEO skills for grow hackers.
An eye-catching and structured graph information will positively affect your post exposure.

Facebook with Open Graph

Facebook is one of the leading platform that strongly encourages the use of OG Tags.
On Facebook, you might already notice some shared links are displayed in different forms.

FOMR 1 – IMAGE Grid on left
FORM2 – Top cover Image


Continue reading

Geek’s way to say things

developer's way to say things

We geeks often have our own ways to express, which might be too geeky for normal people to understand.

Here are some general guides to help you communicating with your geek friends (at least knowing what they are thinking about… )

1. “X is a subset of Y.”


Spoken by Computer Scientists to say that X is a kind of Y, but Y is not X.

Real life examples:
“Matcha is a subset of Green Tea. They are different!”

Continue reading

Continuously Delivering iOS Beta Builds Automated with Travis CI

Over the years, we’ve been building loads of nicely-crafted iOS applications for our clients.

To keep everyone work closely, we send daily builds to our QA Team, beta users, clients, other team members. However, building an iOS is still painful for Project Manager — It involves compiling, uploading the app to TestFlight or HockeyApp,
setting up  Crittercism for collecting crash reports (Those who have experience, should know that you have to upload dSym files for symbolic debug messages), notify everyone on Slack, etc.

Much better if we can automate all these with each Pull Request.


Our engineers came up with a Reusable iOS script for Travis CI to ease our pain. Check out the script at

Idea overview illustration

CI (Continuous Integration) is delightful

CI has delighted us (and other worldwide developers) by being able to :

  • Automate the unit-testing process
  • Standard build settings
  • Maintain a code repository
  • Build fast
  • Support multiple build targets

Delivering builds have never been this easy


However, whenever initiating a project, our engineers have to spare some time (and that’s not short) setting up configurations for CI, including dealing with iOS Provisioning profiles, build settings, dependencies, etc.

Upon spending time setting up a few iOS Apps,

“Are we repeating ourselves?” yelled the voice from inside.

We’ve also noticed that the bottleneck for delivering a build is at the “Developer → QA” process

In legacy time, upon a beta build delivery, the PM has to :

  1. Ask the developer to push code to beta branch
  2. Pull code from the beta branch
  3. Fix cert and dependencies
  4. Build the app
  5. Upload to Testflight / Hockey App
  6. Update dSym file at Crittercism
  7. Notify QA Tester / Client the build is available

By building on Travis CI, we partially saved the PM’s life by automating the building and environment configuring process.
The well-built (and tested) project build is now ready for delivery.

Why don’t we further automate the delivery stage?

Beyond Auto-building – Automating the delivery process

Our engineers prepared a reusable script that basically helps initiate the Travis CI settings for every iOS project.

With proper settings and valid API keys, the deliverable built on Travis CI will then be delivered to other App distribution platforms.

Developers only have to put required the certificates, provisioning profiles and API Keys in the corresponding directories.
Then fill in the blanks for project settings in travis.yml.

The repository also includes scripts that enable signing and uploading. Project code will be compiled upon pushing to branches, then uploaded to Testflight / HockeyApp, and the dSym files will go to Crittercism as well.

Now, the latest build will be built and delivered automatically, available for beta testing in a minute.

“Push and deliver” feels like… (Sorry for Frozen)

Oh, we even have the build result pushed to Slack. So other team members in channel could keep track on the progress.

Get notified with Slack

Life gets better

Required Set-up time for Travis CI : 1 day (Before) → 30mins (After)

Steps to deliver a build : Push, pull, fix dependencies, build, upload to various places, delivered (Before) → Push, delivered (After)

Bonus: Sometimes a project could be built on Bob’s machine but not in Ada’s.
Integrating the CI process also standardizes build settings among developers (CI setting as the standard).

Yeah! That sounds really great now.

Let’s get some coffee.

How to use the script?

Checkout the repository of the Reusable iOS script at .
You may also find guidelines setting up for your project in the project README.

Setting up the certs and provisioning profiles

  • Place all encrypted cert and private key in cert directory
  • Place all encrypted provision profile in profile directory
  • Add encryption secret key:
  • Add protection password for private key:

Upload to TestFlight, HockeyApp and Crittercism

  • Enable uploading testflight branch to iTunes Connect by iTunes Connect account:
  • Enable uploading hockeyapp branch to HockeyApp by adding App ID and App Token:
  • Enable uploading dSYM file to Crittercism by adding App ID and API Key:

If you favor Travis CI for iOS project + more:

Check out the Reusable iOS script at

We wish to see more automated integration that delights our lives.
Pull requests are welcome.



If you find this post interesting, subscribe to our newsletter to get notified about our future posts!


© 2017 Oursky Code Blog

Theme by Anders NorenUp ↑