Developing for the WebKit browser engine

I am interested in developing an iPhone app for the community. iPhone developers have the limitation that we may:

“only use capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); and use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software;”

I see that the Polkadot{.js} extension and Substrate Connect work only with Chrome and Firefox. From what I understand Safari/WebKit does support Wasm. Is there a technical limitation, beyond Apple policy, why extensions or other code have not been written to work with Safari/WebKit?

1 Like

According to this, Wasm is well-supported on Safari, so from that point of view at least, Safari shouldn’t have any fundamental incompatibility with Smotdot/Substrate Connect.

Not sure if anyone already did this but you can create a webapp runs smoldot and you can just open it with your iPhone to see if it works.

For anyone reading this, I’ve also answered here: Embedding smoldot into a mobile application · smol-dot/smoldot · Discussion #600 · GitHub


Have you looked into any hybrid frameworks? Obviously they have some drawbacks, but something like React Native or Ionic work pretty well from my experience. This also means you can take advantage of thinks like the polkadot.js SDK. (example here, using Substrate Connect inside of Ionic: GitHub - CrackTheCode016/ionic-polkadot-light-client)

If you’re looking for purely native dev, wrapping wasm in Swift could be something interesting to look into :stuck_out_tongue:

I was wondering about this as well and tried some things a while ago to unclutter macos native wallet things:

  • From extension perspective tried to port e.g. polkadot{.js} to Safari and failed.
  • Creating something around C or rust bindings in swift did not fly, but that is also around 2 years ago.
  • There seem to be two grant projects for swift ports of the polkadot api which I personally could not make work

From recent developments the smoldot approach could work out nicely, did anyone try that out yet?

I have always stuck with native so I can follow the user interface design patterns of the device (ie - the Human Interface Guidelines (HIG) for Apple, Material Design when I worked on Android). Just a personal preference.

1 Like

Can you point me to the two grant projects for swift ports of the polkadot api?

I have successfully used the Tesseract Swift SCALE Codec (Wave 7 - Q3 2020). I am working on a Swift API built around dynamically generating Swift source code from the Substrate metadata, the same approach as the Polkadot.js TypeScript API: read the metadata, populate a registry, output equivalent Swift source for inclusion in the final API wrapper. My Swift type generation might be of use for your macOS project…I will share my proposal soon.

I am thinking forward into having the API talk to a separate light client API and veered off into assessing impediments and blockers to embedding smoldot. I wanted to check my assumption that smoldot would indeed work on WebKit and then figure out if whatever the iOS SDK exposes is actually a blocker or just an impediment.

Here are some Wasm resources I found for Swift:

Wasmer might be a good fit for your needs. The docs say that it will “allow you to run extremely portable binaries unmodified on macOS”. It sounds legitimate, since there are no alternative web engine restrictions on macOS. They aren’t so explicit about iOS support though. I’ll have to dig into more.

1 Like

I just wanted to clarify that at the moment the fact that smoldot compiles to Wasm is purely an implementation detail. As a user of smoldot, it’s not something you ever interact directly with or care about or anything.

There are two ways to use the smoldot light client: either use the JavaScript library (the NPM or Deno package), or use the Rust library.

Technically, you could compile the smoldot Wasm blob and run it yourself. After all, that’s what the JavaScript library does internally.
However, the interface that the smoldot Wasm blob exposes isn’t stable and I reserve the rights to break it at any point. I have actually just made a lot of changes to this interface, and am planning do it again once browsers support Atomics.waitAsync and in order to support multithreaded execution.

1 Like

Thank you for the clarification. So what you are saying is that it would be advisable to follow the technique of “coding to an interface” while you iterate on the internals of smoldot. Rather than get bogged down in the details of Wasm, I might focus more on having Swift interoperate with Rust and any restrictions in doing that on iOS.

@2075, based on your macOS wallet work, are there any libraries around Swift and Rust you might recommend I look at from your porting experiences?

Just off the top of my head, once you have C bindings it’s pretty easy to do (pub extern "C" or whatever). However, can take some time to setup and get those properly working.

Might I ask what your goal is, to build something that relies on a light client, or just sends extrinsic (maybe both?)

My end goal is to make an iOS-native Swift library with an embedded light client. Completely eliminate remote procedure calls to a hosted server.

I started stepping through this Wasmer project…but I hit an impediment with the deprecated C API it references. I haven’t touched C in a long time, and now I need to revisit how Swift handles interop with Objective C behind the scenes… it’ll probably lead to a dead end but I am curious what it is.

1 Like

I don’t know anything about Swift and I’m not touching Apple products in general, so I can’t help you in details, but my intuition would be to use this project: GitHub - chinedufn/swift-bridge: swift-bridge facilitates Rust and Swift interop.

You’d turn this example into a library, then follow this guide.


I have only briefly skimmed through it, but this looks amazing. Thank you! I am in the process of learning Rust and have been working on transforming the Polkadot metadata into Swift, so it is exciting to see a Rust developer coming at essentially the same problem from the other side. I will have to see how I can contribute to that project; I’m new to open source, but I think my Swift perspective could add some value there.

1 Like