Hacker News Reader

Comment by quelsolaar | Hacker News Reader

Its absolutely crazy to me that both major mobile platforms don't have APIs that are available with bindings for all major languages. Forcing developers to use Java on android (A VM on a low powered platform), and ObjectiveC/Swift(Languages that are barely used on other platforms) is so hostile to developers.

View on HN

I mean, hang on there... Objective-C, while probably frustrating to get started with, is literally "just about C". Projects have been doing Objective-C interop for decades now, very similar to what is being done in the posted article. It's not really gated off at a programming layer, moreso in how Apple's been so frustrating about developing on non-Apple hardware.

It's not exactly what I would call "hostile", language-wise. Swift, on the other hand, might be a bigger barrier...

Yeah, bindings for UIKit aren’t actually all that challenging to write. There’s quite a number of UIKit apps written at least partially in languages other than Obj-C/Swift.

Android Framework on the other hand is not great in this department. Practically speaking it’s just Java and Kotlin. I wish I could write Swift there because even if Kotlin is similar syntactically the JVM baggage can be irritating.

Complaining about the JVM on Android ("a low powered platform") feels like a take that's about 10-15 years out of date. A modern Android phone is several orders of magnitude more powerful, however you might want to measure that, than the machines that Java was first designed for. And anyway, Android doesn't really use a VM anymore - it's been AOT compiling apps on installation for around a decade.

There's about a billion things about developing on Android that are absolutely miserable. HLL-induced perf bottlenecks aren't usually one of them.

I don't think GP's complaint is about Java and Swift being unperformant, I think the complaint is that you can't use the language of your choice easily. If we just had a C API we could interpret Ruby or Python with a standard interpreter. But instead, if you want to write a Ruby or Python mobile app, you need to translate objects between the language of your choice and Java/ObjC.

Right -- Android does have a C API but it’s a pain to use and really incomplete: https://developer.android.com/ndk/guides/stable_apis If you want to do anything else you need JNI which is an even bigger pain.

I don’t really understand why the Android team haven’t made it easy to call any Java API from C, with auto-generated bindings or some such.

I think they just don’t believe in apps using native code, beyond the special case of games (note that pretty much all the native APIs are to do with low-level graphics and sound).

You don't need to wonder, it is quite explicity mentioned on the NDK documentation.

"The Android NDK is a toolset that lets you implement parts of your app in native code, using languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages."

-- https://developer.android.com/ndk

"The NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps. However, the NDK can be useful for cases in which you need to do one or more of the following:

   - Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

   - Reuse your own or other developers' C or C++ libraries.

-- https://developer.android.com/ndk/guides

There is also the security aspect, why they discourage the use of those languages for full blown applications.

Hmm, that explains the situation (native code is discouraged for most purposes) but doesn’t explain why they take that approach.

There is also the security aspect, why they discourage the use of those languages for full blown applications.

Native code in apps doesn’t seem like a security problem on iOS, though?

Why do you think Swift was invented, and there is a Safe C dialect used on iBoot?

Spend some time reading iOS security updates from Apple, lots of nice CVEs fixes reported there.

Swift compiles to native code. C and C++ are well-supported userspace languages on iOS.

Java also compiles to native code on Android.

Try to write an iOS application using only C and C++, instead of either Objective-C or Swift.

"Swift was designed from the outset to be safer than C-based languages, and eliminates entire classes of unsafe code"

-- https://www.swift.org/about/#features

"Swift is a successor to the C, C++, and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics, giving Cocoa and Cocoa Touch developers the performance and power they demand."

-- https://developer.apple.com/swift/#fast

Some of the information related their Safe C dialect,

https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-...

"2023 EuroLLVM - Keynote: “-fbounds-safety”: Enforcing bounds safety for production C code"

https://www.youtube.com/watch?v=RK9bfrsMdAM

Finaly a recent gem from CppNow 2023,

"Introducing a Memory-Safe Successor Language in Large C++ Code Bases"

https://www.youtube.com/watch?v=lgivCGdmFrw

The only point I’m trying to make is that C and C++ are well supported on iOS -- they work out of the box with the standard dev tools and there are plenty of Unix system libraries (e.g. libcurl). On Android, C and C++ are very much second class citizens. I find that a strange decision.

Try to ship an iOS application using only C, C++ and UNIX calls, without touching Objective-C or Objective-C++ in any form or fashion.

How many Android devices are in service in the world? Whats the total power consumption of all Android devices? Shaving just 1% is probably a couple of coalfired power plants worth of CO2.

Embedded carbon from shipping too much DRAM is probably more of an issue.

If no one use smart phone then you can probably bring down more than couple of coal fired plants. Isn't it great?

Objective-C and Swift are used all over the Apple platforms, including desktop macOS. So „barely used“ on other platforms is not really true.

Also considering the number of iOS devices, those two languages are probably more usable in practice than for example C#, even if the latter is cross-platform.

"barely used on other platforms" clearly meant (to me anyway) barely used on non-Apple platforms. They're not terrible languages, but they're pretty uncommon outside the Apple ecosystem.

But the Apple ecosystem is huge. It’s just much more consumer-oriented, in contrast to „corporate“ languages like Java and C#.

The interests of platform vendors and application developers are not aligned.

Platform vendors seek to lock in developers and discourage development on competing platforms, while developers wish to leverage their skills portably across multiple platforms.

Google isn't capable of aligning itself with its own mission, let alone locking in developers. They'll sooner release 10 programming platforms invented for 10 new messaging apps.

Google do maintain Flutter though, which is effectively a competitor.

Given that Swift is open source, I'm surprised Android hasn't made it a 1st party alternative to using Kotlin.

They could capture alot more developers this way, as learning 1 language for both mobile platforms would facilitate more iOS only apps (there are many still even today) to get ported to Android.

This may finally make Android tablets viable, as the app ecosystem for tablets isn't as good as iPadOS

Android has 70% of the world market, there is no reason to care about Swift.

Also Kotlin and Android Studio are mostly developed by JetBrains that is in bed with Google for Android tooling, if anything I expect more Google acquiring JetBrains than supporting Swift on Android.

Objective-C has been open source for even longer, and Cocoa and the associated mobile toolkits eminently clonable. I'm rather more surprised that Google didn't make an 80/20 iOS compatibility toolkit 15 years ago. If they didn't do that then when iOS was dominating the hearts and minds of pretty much every developer behind any noteworthy mobile app, then I wouldn't expect them to make Swift a first-class priority today, when Android has basically "won" on the global scale.

Not kept up with the times?

Since Android 5, with ART introduction, that Android uses a mix of AOT/JIT code.

Java was invented for low end IoT, there isn't anything more low powered than anything in the last 20 years of mobile computing.

Apple and Google should be cherished by not keeping the old C and C++ song of POSIX tunes going.

As Rob Pike puts it, it is like only listening to David Cassidy records.

It's really trivial to use ObjC from any language with a CFFI. and in turn really trivial to expose Swift to ObjC as well, so to other languages.

Just some examples of bindings:

Python https://pypi.org/project/pyobjc/ Rust https://docs.rs/objc/latest/objc/ C# https://learn.microsoft.com/en-us/xamarin/ios/get-started/ob... Javascript https://www.npmjs.com/package/objc

This isn’t so crazy. Apple doesn’t want developers creating a bunch of slow, bloated, interpreted apps.

They really don’t care. Source: every airline app ever, every Cordova or most RN apps

As long as they tie into bringing Apple money- it’s fair game

What’s hostile about trying to provide the best possible APIs for a platform according to the vision of the people creating those APIs?

Reply on news.ycombinator.com