In that case, Kotlin makes even more sense especially with Kotlin Native, and Rust is unnecessary.
Kotlin is already multi-platform and can be re-used as the business logic in iOS apps with Swift as the UI and the Android app with a Kotlin UI (Jetpack Compose) or both iOS and Android apps can be written entirely in Kotlin.
That vastly reduces the maintenance and Kotlin is reused across all apps and keeps it at 2 languages at most.
No need to introduce Rust to achieve the same goal.
This is probably biased by the specific multi-platform apps I've worked on, but my default assumption is that sooner or later, any non-trivial multi-platform app will need to reach for something that doesn't already have a KMP library and that, on Android, might require compiling native code via the NDK. Rust has a way bigger library ecosystem than KMP. So I figure one might as well do the cross-platform core in Rust and add that FFI boundary early, but managed by something like uniffi-rs. And, I've seen it work in a few real projects now, with just a little build system friction up front. So in what sense is Rust uncompetitive for this use case?
KMP can call into native libraries easily. C FFI is not a competitive advantage.
Rust has a smaller library ecosystem, I'd say. Kotlin can use Java libraries on the server side, and on the client side on Android, and the ones needed on iOS are easy to convert to KMP - IntelliJ can do it semi-automatically. And KMP has the libraries that matter on mobile, for hardware access, animations and so on.
I expect that Signal encrypts the notification data prior to sending it to Apple, then decrypts it on-device using a Notification Service Extension – this is a common pattern to avoid trusting Apple with any sensitive data.
That would mean Apple stored the cleartext on-device after decryption.
Signal doesn’t provide anything in the message other than… “there are pending messages.” Signal wakes up, fetches them, then generates notifications on the phone itself.
The 10 hours are not within "normal" business hours – it's a fully remote company. In fact, it's best if they're not – it's a good test of whether someone can communicate well asynchronously (critical for success working remotely).
10 hours a week is very much a second job though. It doesn't really matter when they are, that's a very large commitment over the course of 1-3 months. I'm not sure I know anyone who would be keen to do this.
That's fair – the process has since been revised, and on https://automattic.com/work-with-us/how-we-hire-developers/ we now say "This work is paid, part-time, and designed to last between two and eight weeks, for a total of around 40 hours of work".
It's still a commitment to be sure, but we try really hard to make it as accessible as we can.
FWIW, I'm about as privileged as you get in tech, I have a job that is very flexible, I have few responsibilities outside of work, I don't need the money, and I don't care that much about salary.
I wouldn't work 40 hours spread over 2-8 weeks. It's just too much effort for too little reward. If it were paid at contractor rates then I might – I have done a small amount of contracting in my free time – but we're talking $100+ an hour (and I don't live in the bay area).
I understand the value to the company of a trial, and if I were unemployed I think it would be a great way for me to trial a company, and I'd be totally up for it, but fitting this around an existing job, let alone a family, child, being a carer, or just having an active social life, seems so much more effort than any other tech interview process I've seen.
If Automattic paid 2-3x more than others, then maybe it would be worth it for that chance, but that's not something I see advertised so I assume that's not the case.
Seeing this as part of the process I would be seriously concerned about the sorts of people I would end up working with, as I imagine it selecting for a very non-diverse set of developers who struggle to find jobs elsewhere.
That said, if this is not how things end up, I'd be keen to read a "deep dive" sort of thing on these topics, why the extensive trial works, etc. A full rebuttal to this would be a fascinating read.
One question: is the 40 hours of work something that your company would like to use, that may go into production at Automattic? Or is it just some toy project to work on over that time?
For most engineering roles it's non-production and entirely synthetic, though based on a real app we use internally. It's the same trial project for everyone who applies to the same position.
It's not a one way street, the employee benefits from this as well. You have a 3 month trial to test them out just as much as they're testing you out. You may or may not be happy with this job in terms of cultural or work so it's better than quitting your current job to take another job that you end up not liking.
I think Matt mentioned it on the Vergecast recently, so it's not a secret – we have a team of top folks working on Simplenote and are continuing to invest in it.
Source: I'm on the mobile team at Automattic and just spent a week hanging out with the people working on it :)
One of the big rules is don't repeat yourself – much of the logic only needs to be written once (except UI)
reply