Under The Bridge Under The Bridge

Tag: Android
Mobile App Security: CryptoKit Your Critical Kit

Here’s a set of posts that you should make some time to read if you’re any kind of mobile developer, not because there’s anything strikingly new here — in fact, hopefully there isn’t! — but just to be sure that you have a good basic grounding in 2020’s app security requirements, both for iOS and that other platform:

Mobile App Security: Best Practices on Android & iOS

Android App Security: Best Practices

iOS App Security: Best Practices

Smartphone apps are the center of most peoples’ technology usage. They deal with a lot of private and sensitive user data like your personal health information or banking information. Protecting this data as well as possible is heavily important and the topic of this article.

In this article, we focus on iOS App Security. We’ll show you concrete techniques for making your iOS apps more secure. Our best practices cover means for securely storing data as well as sending & receiving data over the network. You’ll see why it is so hard to get security right and how you can improve your app security by using services from Apple and other providers…

Most of this hasn’t changed much since the last time we did any posts about security here 8-10 years ago, so it should pretty much be a refresher for you, with the possible exception of what you might have overlooked with all that actually exciting stuff out of last year’s WWDC:

Apple’s CryptoKit is a new API that was introduced in iOS 13 and provides lower-level APIs to perform cryptographic operations or implement security protocols.

CryptoKit is based on top of more lower-level APIs. They were available before but introduced additional risk factors since developers often used them in a wrong way.

CryptoKit also allows you to use the SecureEnclave to get cryptographically safe functions that are performant and optimized for the device’s hardware…

So that’s pretty much a solid win all around there, isn’t it? Next time you’re touching crypto stuff, do yourself and the rest of the ecosystem a favor and adopt it! Isn’t a great deal of resources out there, but here’s what we’ve noticed:

WWDC session 709: Cryptography and Your Apps and associated playground

Discover the New Apple CryptoKit Framework

Common Cryptographic Operations With Cryptokit

When CryptoKit is not Enough

CryptoKit and the Secure Enclave

Particularly that last one, if you want really really secure:

For us developers, how the Secure Enclave deals with biometrics is not the most exciting part about it, because we cannot query it directly. Even our biometric APIs are constrained and they are fully handled by the system, so we cannot really do much work on top of that. The real exciting thing is that we as developers can leverage the Secure Enclave to encrypt and decrypt information with keys that are specific to a specific setup in a specific device…

And that’s about it for state of the art security. For your non-up-to-date users, their recommendation is

If you want to support older iOS versions you can use those lower-level APIs or use well known open-source third-party libraries like CryptoSwift.

That one does look pretty much the most comprehensive to us at the moment as well, yep; but there’s a wide variety of libaries in this space with varying focuses, so we’ll just point you at the currently best maintained curated lists with applicable sections — those links should stay relevant for another decade we trust!

Awesome iOS: Security

Awesome Swift: Security

UPDATES:

Introducing Swift Crypto

Swift Crypto is a new Swift package that brings the fantastic APIs of Apple CryptoKit to the wider Swift community. This will allow Swift developers, regardless of the platform on which they deploy their applications, to access these APIs for a common set of cryptographic operations…

Flutter Flutter Little App

 

So things were not all that terribly interesting at Google I/O this year, at least as far as iOS developers are concerned — 

100 things we announced at I/O ‘18

— until you get down to

90. We shipped Flutter Beta 3, the latest version of our mobile app SDK for creating high-quality, native user experiences on iOS and Android…

That’s always an interesting claim, isn’t it? Well, allegedly it’s

Ready for Production Apps: Flutter Beta 3

This week at Google I/O, we’re announcing the third beta release of Flutter, our mobile app SDK for creating high-quality, native user experiences on iOS and Android, along with showcasing new tooling partners, usage of Flutter by several high-profile customers, and announcing official support from the Material team.

We believe mobile development needs an upgrade. All too often, developers are forced to compromise between quality and productivity: either building the same application twice on both iOS and Android, or settling for a cross-platform solution that makes it hard to deliver the native experience that customers demand. This is why we built Flutter: to offer a new path for mobile development, focused foremost on native performance, advanced visuals, and dramatically improving developer velocity and productivity…

Well, to our ears, this has a distinct ring of the claims made for cross-platform development by for instance Xamarin, which tend to not be widely shared by those who actually attempt to ship products with them:

Xamarin SUCKS! Lessons learned from weeks wasted

I’m really sorry for the language, but this software is simply and literally the worst mega f***ing shit I’ve ever used in my life. This halfass piece of garbage only serves to waste people time. And IKR, how could people pay for this, ffs?!

… SO TO ANYONE OUT THERE WHO, LIKE ME, THOUGHT “HEY, IT CAN’T BE THAT BAD, CAN IT? I’LL JUST SPEND A FEW HOURS, MAYBE A DAY SETTING THINGS UP BUT IT WILL PAY FOR ITSELF”. NO. GO BACK. IT WON’T PAY. IT’LL NEVER PAY. IN FACT, IF YOUR DREAM IS TO WORK AT MICROSOFT THEN MAYBE YOU SHOULD STICK TO XAMARIN. BECAUSE YOU’LL FEEL LIKE YOU’RE FIXING XAMARIN’S BUGS, NOT YOURS. IN FACT, SOMETIMES YOU’LL EVEN FORGET ABOUT YOUR PROJECT. YOU’LL BE JUST LIKE “WTF IS THIS PROJECT DOING HERE? OH, IT’S MINE”, BECAUSE YOU’LL BE SO INTO XAMARIN BUGS. YOU’LL START THINKING ABOUT GOING TO GITHUB AND FIX XAMARIN INSTEAD OF YOUR OWN CODE (SERIOUSLY). THIS IS A DISEASE. DO NOT GO ANY FURTHER. YOU’VE BEEN WARNED.

Don’t hold back there, tell us how you really feel why don’t you?

Or, there’s always the trendy flavor of the last couple years before people actually started trying to maintain real apps with it, React Native:

Native > Flutter > React Native

As we all know there are a lot of cross-platform development frameworks but none beats the user experience of a natively developed application. A few months back here I was trying to appeal for React Native. But when I took it for a full spin for a fun project. I fell flat on my face.

There were many shortcomings when it came to React Native. Since mobile applications heavily depend on swipe-based user interaction and React Native heavily depends on a bridge that makes the JS code run on the native engine. This caused a lot of janking due to bottleneck. List Views using React Native was a nightmare…

Well, that fellow is optimistic about Flutter’s potential, apparently once bitten still not shy. Give it a couple more decades, you’ll be cynical as a troll, just watch … either that or burnt out completely, there does not appear to be any middle ground.

For some additional supporting evidence, here’s hands on experience:

How fast is Flutter? I built a stopwatch app to find out.

According to the docs, high performance is to be expected:

Flutter is designed to help developers easily achieve a constant 60fps.
But what about CPU utilization?

TL;DR: Not as good as native. And you have to do it right…

Now, not as good as native, that’s not stopping people shipping apps with it, check out the Showcase here. As we write this, the Hamilton musical app is the flagship example of a shipping cross-platform Flutter app, and the builders veritably ecstaticize themselves over the experience here: 

Rise Up! — The story of how the Hamilton App uses Flutter to do more for its fans

So there is definitely the potential here to suck less than other cross-platform solutions — not to imply that’s a high bar! — and it’s always good to have options available, yes?

So if you are interested in Flutter —

— and it definitely looks worth at least keeping an eye on to see if it gains further traction or slides into the shambling undeadness of past Google abandoned failures —

— here’s some resources to check out:

Flutter @ Google I/O 2018 YouTube playlist from @flutterio

Udacity’s free Build Native Mobile Apps with Flutter course

… and of course the Wenderlich tutorial empire is staking territory out here already:

Getting Started with Flutter

Getting Started with Flutter in Android Studio screencast

Flutter Navigation Tutorial

And if you, Dear Reader, happen to have some experience building a non-trivial application with Flutter, be sure to let us know how it went!

UPDATES:

Flutter vs React Native: A Developer’s Perspective 

Longtime iOS Dev – First Flutter App

The Flutter Report

Flutter will change everything, and is an excellent choice for iOS development

Introduction to Flutter: Building iOS and Android Apps from a Single Codebase

Building a Flutter App with Complex UI

Flutter Versus Other Mobile Development Frameworks: A UI And Performance Experiment. Part 1

How to Learn Flutter in 2020

Takeaways comparing Flutter to Jetpack Compose

The Triumphs and Tribulations of Kotlin/Native In Practice

Cross-platform with Kotlin/Native at PlanGrid

Kotlin Multiplatform for iOS Developers

Kotlin Multiplatform Project for Android and iOS: Getting Started

Maximizing Code Sharing between Android and iOS with Kotlin Multiplatform

KaMP Kit by Touchlab “…to get your mobile team started quickly with Kotlin Multiplatform”

Asterope postmortem

Here’s an inspirational story for you: a detailed chronology of the journey of the game Asterope from concept to the App Store by way of … the Google Android Challenge!

It actually took a while until I started working on the game for real. The deadline for the Google Android Challenge was the last day of February, if I recall it correctly, and although the idea was vividly with me for January I could not get myself to start working on it. I think it had to do with me needing some time to rejuvenate after having stopped working part-time. I almost gave up on the idea with the deadline nearing so quickly, but then Google decided to postpone the deadline to April 14th after they released an update to their SDK. This got me motivated to do it – to take action on the opportunity!

That didn’t work out quite as hoped — although it did get rated in the top quarter which is, well, better than not being in the top quarter, but that’s about it; but then along came the iPhone!

After the iPhone SDK was released I instantly knew that I had to port my game to the iPhone. I could not let Asterope sit still and collect dust on my hard drive…

I instantly fell in love with the device, it had the most beautiful UI I had ever seen on a phone. And it just worked! I’ve had seven Nokias in the past but never have I been as impressed with a phone as I was with the iPhone. It’s just a huge step forward from anything previously on the market.

In late August I had the iPhone, a Mac Mini to develop it on and time to make it happen. Time to roll up my sleeves. I could not let myself pass on this opportunity. And I tell you it felt almost scary knowing I might have everything I need to make a commercial game with potential to make a lot of money.

Heartwarming story, isn’t it?

h/t: Slashdot!

developers developers developers developers

Yep, there may not be much MonkeyBoy gets right at Microsoft, but that was one: It’s all about the developers developers developers developers. So it behooves us to keep an eye on how iPhone developer interest is comparing to those other, lesser, mobile platforms!

Over at O’Reilly Radar there’s a fellow who’s taken a first stab at it. Unfortunately, his main metric of mailing list posts is utterly worthless, as anyone with the iPhone SDK is still under NDA, so can’t legally post anything about it on public lists. However, this graphic contrasting the sources and magnitudes of jobs for iPhone, Android, and Symbian development is worth some consideration:

Well, we’ll see how that chart looks in a year, won’t we now?

h/t: MacSurfer!