Go to compare.rokka.io/_compare and compare the output of the HEIF, JPEG and WebP formats. Even upload your own pictures. All done with rokka.

Long version

Apple produced quite some hype with their support for the HEIF image format in the upcoming iOS 11 and macOS High Sierra. HEIF (High Efficiency Image File Format) is a new image file format, which supports many use cases and uses HEVC for the compression part, also known as H.265. Apple is using HEIF on their latest devices as a replacement for storing pictures and claims up to 50% saves on storage.

Even though no browser does support HEIF yet, also not Safari in the current betas, we nevertheless thought it would be cool to add HEIF support to rokka – our image storage and delivery service. And so we did.

Unfortunately there's no out-of-the-box solution to create HEIF files currently. But Ben Gotow‘s site jpgtoheif.com inspired us. He published instructions how to create HEIF files with the help of ffmpeg, x265 and Nokia's heif writerapp. But due to the uncommercial-only license of that Nokia code, we use GPAC to create the HEIF container, which is published under the LGPL license.

Looking at and comparing HEIF compressed images

What's the fun, when almost no one can look at the result? So we built a little site, where you can compare the output of rokka's HEIF, JPEG and WebP (the later is only supported on Chrome) and even upload your own pictures. Just head to

compare.rokka.io/_compare

and enjoy it. The uploaded images will be deleted from time to time.

The site uses Nokia's HEIF Reader JavaScript Implementation, which decodes a HEIF image in JavaScript to a canvas element. This way, everyone can look at HEIF images and compare them to JPEG and WebP output.

The site also allows you to play with different quality settings. All formats support a setting from 1 to 100. 1 is the lowest and 100 the highest (also means lossless for WebP). The different quality settings for the different formats don't really correspondent to each other. Just play around with them and compare the sizes of the images with different settings.

We use pretty much the default settings of ffmpeg, maybe some stuff could be improved on that side. And we also don't know what kind of encoder Apple is using for generating HEIF images. So don't really compare the compression we produce for HEIF images with what maybe other encoders can do.

Also be aware, that we asynchronously compress JPEG images in the background with mozjpeg (see the rokka docs for details), so the first render output is not the maximized compression we can get for JPEG images. Just hit the render button 10 seconds later to get the final compression (the site will inform you, when it's not done yet with that compression step).

Some clarification is needed.

The Difference Between Native and Hybrid Apps

In this article, we talk only about apps that one can download from an app store (and not about mobile websites).

Native apps are mobile applications that are written in a native language such as Swift for all Apple iOS apps, and Java for all Google Android apps. You have to write the code two times, once for each platform, which results in more development and maintenance work.

Hybrid apps are based on a single codebase that produces mobile apps for both Apple and Google platforms.

Both native and hybrid applications are on app stores. Both are downloaded on your iPhone or Android smartphones. Both can be opened. Both can send push notifications. Both can be deleted from your smartphone. No matter what's inside.

Native or Hybrid App, Which One Should I Build?

“All this is very interesting, but what should I use for my next mobile product?”, you may wonder.

At Liip we use the following criteria to guide our strategy:

Internal Business Logic If the app contains more than 50% business logic stored on the smartphone directly (vs. business logic stored at a backend server), then it's worth investing into a hybrid solution as the mutualization of code will have a significant financial impact on the project. An example we worked on is the Schindler elevators mobile app with its offline requirements that required to store the logic on the smartphone app.

In the other case, we favor native mobile apps.

Custom Design When the app has a lot of custom visual components (e.g. not the default list views proposed by Apple or Google), then we recommend to craft a native app as the hybrid approach wouldn't bring any mutualized value here because you anyway have to build custom User Interface for each platform.

On the left is a list using standard Apple iOS visual components, and on the right the example of the UEFA Champions League mobile app with a custom list view.

Reliance on Third Party Plugins If your project relies on one or more third party plugins (aka SDKs), like for instance Tealium (a data management tool including Analytics monitoring), then we recommend to build a native app. These plugins are written in Swift and Java so you never have compatibility issues with native apps.

This criteria comes from an experience we had where we spent a lot of time integrating a third party plugin within a Xamarin hybrid app project.

It is a Weighting Game

As we often claim, we are not religious with technologies here at Liip. There is no magic formula that can be applied to all projects; we always have to ponder each criteria together with the client in order to find the best fit for his situation.

Do you have experience with one or the other kind of mobile application? Bad or good, share your story with us.

We booked a one-day hands-on with Noé in our ThinkSpace war room with the objective to have a demo app up and running and plugged to the SAP Cloud Platform (formerly known as SAP Hana). This may sound like an easy goal but honestly, knowing SAP, we thought that it was already ambitious.

Lesson learnt #1: One can easily create a SAP Cloud Platform demo account

We imagined it would require many days to have our Liip's SAP Cloud Platform up and running with validation processes and all. That's old-thinking. It took Noé less than half an hour to have it ready.

It may be different with a production environment but still, the developer experience was great as one can have a playground and try to build a Minimum Viable Product (MVP) straight away.

Lesson learnt #2: The SAP SDK provides a skeleton app — really — ready to play with

When we browsed the tutorials on the SAP blog, we're again (positively) surprised to see that the SAP team crafted a demo app that was supposedly ready-to-use. And it was!

In less than 3h, we installed the app, and connected it to our Liip's SAP Cloud Platform from which we could read and write data. It actually required more time to register and activate all needed modules in the SAP Cloud Platform than to actually deploy the app on Noé's iPhone!

Lesson learnt #3: iOS SAP SDK documentation is not centralized enough

One drawback SAP has to fix if they want developers to catch-up on their new tools is the documentation. Although the skeleton app works out-of-the-box, we had hard times to follow the setup steps which were spread over the main homepage, various tutorials, and other articles. For instance, there are several modules and settings to configure and we took a lot of time to figure it out. If some SAP engineers read these lines, please keep up the good work and remove the complexity from your documentation.

Our SAP iOS mobile application demo

Lesson learnt #4: “SAP Fiori for iOS” documentation is complete and well structured

Compared to the previous point, the User Experience and Design documentation of SAP Fiori for iOS is impressive: it is well structured, complete, and easy to get through. All usual business use-cases are covered in a deep manner with all needed details about user flows.

I can't help but recommend the development department at SAP to follow their path as it would help the community to engage more, and as a result their products would take off more quickly!

SAP Fiori for iOS User Interface Example (credits: SAP website)

Lesson learnt #5: User Interface customization will take you more than a day

Once we got the app and SAP environment ready, we dived into the code in order to play with screens' layout and data flows. As one might expect, that's what the demo app is for: testing in a playground. But when we wanted to customize the design to match our Liip corporate identity, we saw the limitation of the demo app: although it's not a blocker at all, it's good to know that it will require you more than a one-day workshop to get it implemented.

Summary

Below is what we achieved in less than a day with this new iOS SAP SDK:

• Setup of a Liip SAP Cloud Platform demo account with sample data
• Running an iOS demo app on our iPhone
• Live synchronisation of data between the app and the SAP Cloud Platform
• Dive into the “SAP Fiori for iOS” documentation

Did you play with the SAP SDK for iOS yet? Or even better, did you already release publicly an iOS app based on SAP? I'd be glad to share on the topic around a coffee or via the comments' section below.

I have this discussion every week with new clients, and I thought it was time to share our reasoning here at Liip in order to give you a clear answer if you still hesitate.

Do You Want To Reach Your Users, or Bring Rich Features to Them?

When clients come with a mobile app request, I explain them that most of the time, a web application is more efficient in terms of investment, as well as in term of reach.

The second question I get after this answer is: “When would I need a mobile app, then?”

In my point of view, mobile apps are useful when they are crafted to be rich — vs. the reach that web applications can provide. Rich in terms of features that are only available on mobile devices, and that can't be achieved via web technologies.

Here is a non-exhaustive list of smartphones features that could be useful to your product:

• Bluetooth — to connect to a supply chain system
• Geolocation/geofencing — to contact only the employees you need (i.e. avoid information overload), such as with the TPF Houston product
• Beacons for indoor localization — to guide a user based on its location context
• Push notifications — to inform people in a timely manner like goals scored in the UEFA Champions League app
• Camera usage — to scan a barcode to identify a drug such as in our Patchie medical project
• Augmented Reality — to enhance human capabilities like the Daqri innovative tools which we investigate currently
• Fingerprint authentication — to improve the User Experience by shortening the “painful” steps such as entering your password
• Offline capabilities — like the offline local search in our Schindler app for elevator repairers

Loyalty vs. Visibility

If you are already established on the digital market, a mobile app is a great loyalty tool to invest in, as it engages your audience more. From the comScore 2016 App Report, one can learn that users spend 20x more time on apps than mobile website visitors. A bit like if an app created a bubble of attention focus. Something that the web, by essence with its linking nature, doesn't provide to visitors.

Users spend 20x more time on mobile apps than on mobile websites (Credit “comScore 2016 U.S. Mobile App Report”)

However, if you aren't known yet, a website viewable on smartphones/tablets/desktops might help you to stand out as the average monthly audience is 3x more important on websites than on mobile applications.

Mobile websites reach 3x more visitors than mobile apps (Credit “comScore 2016 U.S. Mobile App Report”)

It's Not a Religious Choice

The time when you needed to choose one way or the other is behind us. Both solutions have their pros and cons, depending on your needs. In an ideal world with unlimited budgets and no deadlines, both solutions should be implemented for different purposes.

If you're not in this comfortable solution, you better start with what is the most critical to your business: engage more an existing audience? Or expand your audience reach?

Rich vs. Reach — The Summary

If your objective is to provide a rich experience to your clients, using the full native features offered by the latest smartphone, then you should go for a mobile application that will allow you to retain them longer.

If you're in the B2B sector or have internal needs, then there are even more chances that a mobile app is a good choice for you. A choice that can leverage smartphones' native features that are often what can bring more efficiency and productivity in industries.

If the goal of your new product is to reach as many customers as possible, and that you don't need to access to specific smartphones capabilities, then you should go for a web application.

“Mobile apps engage an audience. Mobile web expand audience reach.”

I'm always interested to challenge assumptions when it comes to choose between a mobile application and a responsive website, so don't hesitate to share your use cases in the comments section below, or come to our office to chat around a coffee.

First of all, it is important to carefully chose between a web and a mobile application. Mobile apps are useful when they use one of the device's native capabilities (e.g. Bluetooth, GPS, camera, etc.), and when they enhance the experience provided to the user (compared to what a web application could do).

Industrial challenges

The challenges industries face are often very good candidates for mobile apps as they leverage all their potential. Therefore, I have identified five recurring issues that industries are facing nowadays. These pain points can be easily relieved by mobile applications.

Challenge 1: Productivity issues due to technical limitations

In some industries, technology gets old and sometimes stands in the way of employees' productivity. Our project with Schindler is a good example: technicians had to go inside the elevator shaft, detect the default, take note of the spare part reference, go back to his vehicle or office to check the catalog, to finally be able to identify the issue. Now, technicians can access the catalog directly in front of the problematic spare part, and shorten its identification by 30%. It increases process speed, elevators are fixed quicker. As a result, the users are happier, and it is profitable for the business.

Time for an industrial digitalization?

Challenge 2: Reduce existing operating costs

In the recent project implementation of HOUSTON, we saw how mobile technology could help to reduce drastically the operating costs of a client's existing radio infrastructure. With the use of new technologies such as VoIP (via the  Twilio service) coupled with mobile apps, we managed to decrease their total maintenance costs by two.

This kind of Return On Investment can auto-finance the project thanks to the realized savings. The funniest in this case is that the true ROI comes afterwards when the employees enjoy a better User Experience.

Challenge 3: Inflexibility due to stationary machines

Similar situations occurred for several industrial audits we performed. For instance, our watchmaker production line, where we implemented a web application based on an API in order to satisfy the brand's IT and security regulations.

We are convinced that the next step of their digital transformation is: go mobile. Drop the static machines, allow people to prepare their procedures and actions on the mobile app, and let them connect to the manufacturing production line via Bluetooth to execute the commands needed there. This way, employees wouldn't be tied anymore to a location. Way more convenient and flexible.

When a production line goes mobile, employees will save on-site time, as all their supply chain procedures are prepared in advance on their mobile app.

Challenge 4: Slow reaction time to alerts that generate high risks

Most of the industries need real time monitoring to ensure that supply chain risk levels are kept to their minimum. This implies costly equipments as well as human resources to track possible failures and malfunctions. Thanks to push notifications and other real time capabilities, mobile apps can both increase reaction time with their timely alerts, and decrease monitoring costs.

Challenge 5: Information overflow that leads to misinformed decisions

In older systems, information is often spread without the capacity to target users based on their profile or location. As people are spammed, they take decisions that are misinformed as they can't keep up with the load of data received.

Back to the HOUSTON example: mobile app built in GPS capability enables buses' agents to be geolocated. Thus, messages can be geo-targeted to provide the relevant information to the right employee. No complex locating system needs to be setup.

To conclude: Carefully choose how to invest

Mobile apps can solve specific industrial problems. By experience, we have seen that the best mobile app solutions are the ones who answer one need or problem, by leveraging the native devices capabilities. This kind of app that solve a problem in the employees' everyday life is what make them worth investing in.

It is necessary to take time to analyze your issues in order to define the best possible options to reach your goals. Appropriate workshops will ensure that you make the right investment.

We are happy to hear your existing challenges in the comments section below (or simply contact us and let's have a coffee), so that we exchange feedbacks on your struggles.

Last month my colleague Kilian and I were pleased to attend the Swift Alps Conference, an experimental conference about Swift taking place in the Swiss Alps. This conference had a different format from what one can expect from a typical software development conference. In this case the format was more focused in experimenting and collaborating with other attendees with the goal of learning something new.

Experimenting with strangers

The first session of the animation workshop with @manuelescrig at #swiftalps is in full swing pic.twitter.com/9Cumo7sks3

— Liip (@liip) November 11, 2016

The venue was located in the Swiss canton of Valais,  in Crans-Montana, which is a ski resort in the heart of the Swiss Alps.

The combination of this specific location with the amount of  snow, made the conference even more magical, if possible.

Views from the venue

Current view from the @swiftalps pic.twitter.com/f77uIsDAjt

— Manuel Escrig (@manuelescrig) November 11, 2016

Talking about animations

My colleague Kilian and I were in charge of being mentors and creating a workshop about animations in Swift. We decided to talk about how animations can improve the overall user experience of an app together with all the different benefits that they can bring to the user. In addition we talked about the 12 basic principles of animations in design.

Slides from the workshop

The main part of being a mentor in the conference was running different workshops during the day where attendees could join and build/create/learn something new related to the topic of the workshop. We proposed to the attendees to build something with animations using Swift. The 3 proposals we gave were, 1.- Snow background effect, 2.- Cowbell notification badge and 3.- Cheese view transition. Here we'll just cover the first proposal of how to implement a snow background effect using Core Animation in Swift.

Snow background effect

Using CAEmitterLayer from Core Animation we accomplished the following result.

In order to accomplish the effect, we need to create an instance of  CAEmitterLayer, then append to that instance of CAEmitterLayer the different CAEmitterCell that represent the snow flakes.

func startSnowing() {
    emitter = CAEmitterLayer()
    emitter.emitterPosition = CGPoint(x: view.frame.size.width / 2.0, y: 0)
    emitter.emitterShape = kCAEmitterLayerLine
    emitter.emitterSize = CGSize(width: view.frame.size.width, height: 1)

    var cells = [CAEmitterCell]()
    cells.append(snowFlakeWith(color:UIColor.white))
    emitter.emitterCells = cells
    view.layer.addSublayer(emitter)
}

To stop effect, just change the birthRate parameter in the CAEmitterLayer instance.

func stopSnowing() {
    emitter?.birthRate = 0
}

You can append to CAEmitterLayer different instances of CAEmitterCell with different behaviour in order to accomplish a natural movement.

func snowFlakeWith(color: UIColor) { 
    let image = #imageLiteral(resourceName: "flake") 
    let whiteImage = image.maskWithColor(color: UIColor.white) 
    let flake = CAEmitterCell() 
    flake.birthRate = 50.0 * intensity 
    flake.lifetime = 14.0 * intensity 
    flake.lifetimeRange = 0 
    flake.color = color.cgColor 
    flake.velocity = CGFloat(350.0 * intensity) 
    flake.velocityRange = CGFloat(80.0 * intensity) 
    flake.emissionLongitude = CGFloat(M_PI) 
    flake.emissionRange = CGFloat(M_PI_4) 
    flake.spin = CGFloat(3.5 * intensity) 
    flake.spinRange = CGFloat(4.0 * intensity) 
    flake.scaleRange = CGFloat(intensity) 
    flake.scaleSpeed = CGFloat(-0.1 * intensity) 
    flake.scale = 0.1 
    flake.contents = whiteImage?.cgImage 
    return flake 
}

Link to the project example.

github.com/manuelescrig/SwiftAlps2016

Summary

We want to thank the Swift Alps conference organizers for creating and putting together such an awesome event! Indeed, by looking at the reactions of the people, we can say it was a great success. Also thanks to the other mentors for sharing all their knowledge with us, and spending time together. Finally a big thank you to the rest of the participants for bringing such a cool vibe to the conference, making it a really special event.

Manuel Escrig @manuelescrig

In our multilingual iOS projects, we always struggled to translate storyboards in Xcode. We checked all around CocoaPods, but couldn't find any efficient solution so far. Every time, we ended up with multiple versions of the storyboard along with multiple versions of ‘Localizable.strings'. It was hard to keep everything under control, specially when translations needed to be updated throughout all files.

During our last mobile project, we asked ourselves: “What if we could only have one set of translation files that could be used in the storyboard and Swift?”. We brainstormed, and created a modular library to handle this painful task. Today we are happy to release and open source this lib. You can find the code on GitHub.

Introducing LiipKit

Translation

Our main requirement was to have only one set of translation files (i.e. one for each language). This should work on two aspects:

1. Get a translation from Swift
2. Translate a UI component from the storyboard

And this is how it works:

Swift translation importer

import LiipKit
let my_test_translation = ~"test"

Translation within the storyboard

UIButton, UIBarItem and UILabel have a new attribute “Localized Title”.

There is more to come

On top of the translation module, we already implemented helpers on String, Int, and Date. We're constantly adding new features to our LiipKit library, so be sure to watch the GitHub repository.

We welcome any input, feedback, or pull request.

Swift 3.0 is an open source language that has been developed by the community together with Apple Engineers.

One of the great things about developing an open source language is that everybody can see the evolution of the language and inspect the code. In the official release notes there is a list of all the changes that have been implemented in the new Swift version.

Swift 3.0 is also the first release to include the Swift Package Manager, a tool for managing the distribution of Swift code trough dependencies.

Top 10 changes in Swift 3

Enums

1.- Import Objective-C Constants as Swift types

Parameters

2.- Consistent first argument labels

3.- #keyPath

4.- Better translation of Obj-C APIs

Functions And Closures

5.- Closure parameter names and labels

Collections

6.- Remove the ++ and – operators

Good Looking C

7.- Import as member

8.- Modernizing Swift's Debugging Identifiers

9.- Modernized dispatching

API Design Guidelines

10.- Removing ‘NS' prefix

The ‘NS' prefix from key Foundation types is getting removed in Swift 3.

See SE-0086 – Drop NS Prefix in Swift Foundation.

For those who want to read more about it: Apple has released a free book about the Swift Programming Language (Swift 3 beta) on their iBook store.

Migrating from Swift 2.2

Swift 2.2 unfortunately is not supported with Xcode 8 anymore. This means that you will need to migrate your current projects to Swift 3.0 if you want to compile them with the new Xcode.

The problem is that all the 3rd party libraries need to have the same version as your Swift project. And some of them may not be ready yet.

In order to make the transition smoother, Apple is still supporting Swift 2.3 in Xcode 8. Swift 2.3 is almost identical to 2.2.

How to migrate?

Xcode 8 includes a migration tool in order to “help” with the process. A reality check revealed that after using the tool you will end up with a list of warnings that you will have to fix manually.

There is a good article by Jesse Squires on how to migrate libraries from Swift 2.2 to Swift 3.0 that I highly recommend.

What next

Swift 4

Chris Lattner, a senior director of the Developer Tools Department at Apple, posted a lengthy note to the Swift mailing list today that looks back at the development of Swift 3.0 and sets some expectations for Swift 4.0 next year.

Apple is planning to release two major Swift updates next year. Swift 3.1 in spring and Swift 4.0 in Fall 2017. For the development of Swift 4.0 there will be two stages. During stage 1 Apple would like to focus on source and ABI stability first, and then move on to other features in stage 2 depending how much extra time there is.

To read more about Swift, visit swift.org

Doing Agile at Liip does not always mean we live in a continuous flow of sprints, endlessly. Sometimes the comfortable stream of sprints breaks for a while, usually between two projects. This is often a good opportunity to hack on new technologies or try something new. We recently had one of these break and it was the perfect time to try once again our innovation process.

In fact, this process starts before we have one of those breaks. First of all, the whole team lists any innovation idea – could be anything – and anyone is invited to contribute (at the moment we have a dozen projects listed). We try to groom this list as often as possible to keep it relevant. Then, when time comes we can just go to this list and grab a project we want to work on.

Doing innovation keeps us close to new technologies.

The project: an Apple TV app

As part of the Liip “Native apps” guild (officially named “Mobile” guild internally, but we might refactor it looking at the TV screen sizes!), the choice was almost obvious: we decided to hack on the new Apple TV, now opened to developers. The exciting aspect of this device is closely related to the unusual screen size connected to it. The remote also gives us a new TV experience (still from a developer perspective, I am not trying to sell anything).

The idea was simple. I wanted to adapt the mobile application of one of our client, UEFA, for Apple TV. They have lots of photos and videos, so basically the perfect content to play with.

Xcode 7 has already everything for tvOS (Apple TV dedicated Operating System) with its own SDK and simulator. Only a few clicks are required to get started and have a “Hello world” app up and running.

Then we had to go through the basics and learn the visual guidelines. These two links are worth reading to get to know the environment, even if you have been using the previous version of Apple TV. Lots of new visuals have been added, though I really fancy the  Focus and parallax.

Then, coding for the TV is basically the same as coding for other iOS platforms. It took us roughly six man days to create an app from scratch with 3 pages containing different media content (photos, videos) coming from an API. The result on a big screen is very rewarding!

Now what?

We are going to discuss with several of our clients where such a big device would bring added value to their end users – e.g. e-commerce domain and sport' industries.

Also we plan to use this knowledge internally for some potential dashboard apps.

We will keep you posted with our next findings/experiments.

Yes, there is the Interface Builder and it is a great tool, but sometimes,

things get more generic and building the views and layouts can be more efficiently done by hand.

Except – layout constraints! Writing layout constraints can be tedious work.

Example, making an element the half of the width of its parent element in objective-c:

[self.view addSubview:centerView];

// Width constraint, half of parent view width
[self.view addConstraint:[NSLayoutConstraint constraintWithItem:centerView
                               attribute:NSLayoutAttributeWidth relatedBy:NSLayoutRelationEqual
                               toItem:self.view attribute:NSLayoutAttributeWidth
                               multiplier:0.5 constant:0]];

It is not much better in C# with Xamarin either:

View.AddSubview(centerView);

// Width constraint, half of parent view width
View.AddConstraint(
    NSLayoutConstraint.Create(centerView, 
        NSLayoutAttribute.Width, NSLayoutRelation.Equal, 
        View, NSLayoutAttribute.Width, 
        0.5f, 0f
   )
);

But behold! There is our ConstraintHelper!

ConstraintHelper.Attach(centerView).WidthOfParent(0.5f).Top().Center();

The ConstraintHelper is a small C# library to help with the layout constraints and it brings less common concepts like Method Chaining to the layout constraints.

ConstraintHelper is Open Source and can be forked from GitHub.