• Decrypted Kernels As you know, the first beta of iOS 10 came out with kernel cache being decrypted. Initially it was considered as a leak, but Apple confirmed that it was intentional. Time to exlore goodies!

• Text handler for iOS 8 (source editor extension). One of the first source editor extensions for Xcode 8 for various simple text manipulations, like URL encoding/decoding, JSON formatting, UIColor to/from HEX. Might be a source for inspiration.

• WWDC 2016 Developer Perspective The light of WWDC star is still coming in… Realm has captured a lot of “live sessions” about the most exciting parts from a developer perspective.

• Awesome Swift A collaborative edited and well-organized list of awesome Swift libraries. If you search for something something you should definitely try it out.

• Swift Algorithm Club Quite a lot of algorithms and data structures for refreshing your memories and/or checking for how to use Swift for those kind of tasks.

• GraphQL for mobile Nice review of GraphQL from mobile developer perspective if you wish to know something before (or instead of) digging it by yourself.

A short digest of mostly low-level things which started to appear on WWDC’16.

APFS - Apple File System

That’s my personal favorite news.

• For all spectrum of devices
• Optimized for SSD
• Encryption
• Copy on write, snapshots, clones
• Planned release - 2017
• Specs and docs will be available after release

There is no information available on how long it has been in work and how long it was tested.

Language(s)

• Objective-C got __auto_type declarations (source), it can be used like this:

int main() {
   __auto_type foo = @"FINALLY";
   NSLog(@"%@", foo);
}

• Objective-C got also class properties
• Swift in Xcode 8 will be presented in 2 flavors: 3.0 and 2.3 for those who want to wait a bit before jumping to 3.0 train and still want to use new SDKs.

Tools

• new fancy documentation. You have to check it out
• thread sanitizer
• address sanitizer (Swift)
• memory graph debugger
• automatic code generation for Core Data models
• new signing system

The “fun” thing though is that all those changes (except signing system) require migration to Swift 3.0 (if you’re using Swift, it looks like for Obj-C there are no constraints).

libdispatch

• dispatch_assert_queue and similar can be quite handy. See the whole family.
• assertions if there is a hang detected due to a deadlock in dispatch_barrier_sync
• os_unfair_lock (kind of OSSpinLock “compatible” with iOS)
• Cleaner Swift API

Performance improvements

• _NSDictionaryM combines buffers for 33-50% fewer mallocs source
• CFStringCreateCopy early-outs for tagged pointers now, which makes it 4x faster for ~40% of strings source
• NSArray and CFArrayCreate* will now return _NSArrayI and _NSArrayM instances on iOS/watchOS/tvOS as they have for some time on macOS source
• CF_IS_OBJC is way faster (used in bridging) source
• plist encoding/decoding should be a bunch faster due to various changes source

Miscellaneous

• BNNS basic neural network subroutines more
• SFSpeechRecognizer you can guess what it does
• Unified Log API

A short digest for this week:

• Mutexes and closure capture in Swift very through overview how absence of threading language features hits Swift performance.
• Lenses in Swift another attempt to bring functional techniques to Swift.
• Another take on lenses in Swift (video, ~35 min)
• Modern Core Data a couple of tricks on Swift type system to improve Core Data experience (in case you still have to use it). It’s a bit funny to see it this talk on Realm page.
• Using Swift protocols to separate socket functionality is an example of how APIs can be separated to.
• TensorFlow on iOS sounds quite interesting for weekend hacking.
• SwiftTrace is a library for tracing method calls by class for Swift and Objective-C.

It took a bit of time, but finally fsync is available in the AppStore.

From a user perspective it’s a pretty simple iPhone client for syncthing. If you never heard about syncthing and you ever needed a self-hosted Dropbox you should give it a try. It’s very nice piece of software, it runs almost anywhere (Linux, *BSDs, Windows). It’s open source and written in Go so if you want to practice Go language - you’re welcome to contribute.

Right now fsync works in mostly “read-only” mode, i.e. you can view files, you can delete them, but there is no way to edit. This is gonna change soon.

From a technical perspective it’s probably one of the earliest iOS applications, which are partially written in Rust.

There is a lot of things to talk about and I hope to provide more technical details in the following posts, while this one covers using Rust as a language for mobile development from my experience.

In earlier post I’ve written about switching to write-only mode inspired by Joe Nelson. This time I’ll provide a bit more details on why and how.

By accident I’ve read today about Joe Nelson’s life experiment.

It’s a really inspirational post for me as it resonates a lot with what I’ve though about recently. I can argue a lot of minor details (because “but the great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude”), but I can’t agree more with general direction the author takes.

I believe that one of the most limiting factors for current civilization is a culture of consumption. We have too much to consume and our uncontrolled consumption as a result “consumes” our time and available resources, leaving no opportunity to produce and create something.

It’s especially true for developers as we’re overhelmed by available technologies/frameworks/libraries/languages and are interested in trying “one more” shiny, just released thing, which is awesome and just got to HN. I’ve personally done that mistake dosens of times and I’m gonna tell about the recent one in the following posts.

To clarify: it’s not about sticking forever with old tools. It’s about clearing as much space/time as possible for generating new things/thoughts/ideas/products.

I’m not sure I’m ready to formulate it more clearly now, so I’ll start a REPL with my own experiment - instead of limiting myself, I’m going to make sure that I’m in “write only mode”.

What’s the write only mode? It’s the mode where I produce at least as much accessible output as I consume in my expertise areas. Preferably it should be a publicly available output.

The idea here is that it’s actuallly impossible to stop consumption by itself - it’s a dead end, especially in non-expertise areas. But what really makes a difference is what comes out of consumption - my only joy or something others can also use.

Continuation: considerations and setup

It’s been a while since last status update, but I hope it was worth waiting. Rust is now completely ported to iOS: all architectures for device/simulator are supported. Since green threads were removed, adding support of arm64 was actually almost straightforward. Special thanks this time goes to Will Glozer who was debugging remotely. Fortunately for our sanity, there were just a couple of minor issues.

Although all changes have been landed to master, cross-compiled libraries aren’t distributed with nightly, so in case you’re interested in trying it out, you can either build it from source (instructions) or use a pre-built dist.

As earlier, the main usage sample is located here. It still uses makefile based approach and I hope to update for cargo a little bit later.

Since I’m tracking Rust nightly and documentation from the last release was quite outdated, I’ve wrote a quite simple (at least I think so) docset generator for Dash (wonderful piece of software).

Here is the link to feed which is updated once new nightly released.

Once it was complete, I’ve understood that I’d like to see docs for my libraries in Dash as well and here is what I’ve got: rust-docset - it is a Python script which allows to generate Dash docsets and feed from any Rust docs.

It requires a pretty simple TOML manifest to be available, like this one:

[docset]
name = "Piston"
bundle_id = "piston"
version = "0.0.1"
type = "docset.rust"
doc_dir = "../doc"
out_dir = "doc_out"

[feed]
base_url = "http://s3-us-west-2.amazonaws.com/net.vhbit.rust-doc"
upload_cmd = "./upload.sh"

and upload.sh might look like this:

#!/bin/sh

s3cmd put -P $1 s3://net.vhbit.rust-doc
s3cmd put -P $2 s3://net.vhbit.rust-doc

While it started as Rust only project, I believe it could be relatively easily programmed to work with documentation generated by other tools.

Current state

About a week ago it was finally merged into Rust master branch which is really great as it is much easier to work on smaller changes now.

Here are instructions on how to build it. So far there is no official iOS buildbot and therefore it might broke at any moment, in this case I recommend to use a original fork which could be considered a “stable” branch, tested to compile and work both on device and simulator. It might lag a bit from the master but not that much.

There is still one issue in LLVM which sometimes crashes compilation process. Patch was submitted but considering previous experience I wouldn’t expect it to be landed in less than a month.

I’ve started work on Arm64 port but it definitely will take much more time considering I have no test device.

Although there is no public indication, work on porting Rust to iOS continues, moreover it is going to the final stage. So far I’ve got all required pieces working:

• fixed issue with mutexes crashing libgreen/rustuv runtime
• got a working patch for LLVM to support segmented stacks
• got working unwinding (another patch to LLVM compiler-rt)

In general, all major features are working now, providing first-class support of all Rust safety. There definitely might be small hiccups here and there but I believe they could be solved step-by-step, once the major part will be upstreamed to Rust master branch.

I need some time to clean up the code (as it has a lot of experimenting branches) and once patches to LLVM and compiler-rt landed - the last step will be rebase on current master and issue an PR.

I hope it will be finished this week.