This post is my reply to a comment by @alexander_slesarev on Referendum #62: Metadata for offline signers.
The quoted blocks are the comments that appear on Polkassembly. My responses are the bullet points beneath the quote blocks.
- Yes, eventually it would inevitably be developed by us or another party. We could build a rust-based API similar to how Polkadot Vault works, or something Swift-native. The protocol would be published - maybe it would be you who would implement it?
- We are not going to use payment NFC stack. The protocol is based on the most basic and widespread NFC protocol - packets are just written as NDEF messages with no particular response expected.
they have power to do anything with their hardware - and we have the power to build an external NFC communication device if needed.
Attempting to bypass Core NFC to access device hardware could result in rejection or expulsion from the App Store.
I would suggest asking Ledger R&D if they considered NFC vs Bluetooth when designing their Nano X product.
- We have not contacted Apple on publishing anything at all; I would not expect this to be an issue - the app would have simpler functionality that Polkadot Vault (that I was releasing through AppStore at some moment in history, the only thing they had issue with was airplane mode requirement)
The Polkadot Vault code referenced from Polkadot Vault with source code located at parity-signer will differ in at least the following significant way:
I strongly urge that Kampela contact Apple directly for further guidance and clarification.
Included with every Apple Developer account membership are two free TSIs (Technical Support Incidents) that can be used to request code level support. TSIs can also be purchased as needed. Perhaps Polkadot Vault could submit a TSI on your behalf.
and apps like Nova wallet that would just make Kampela interface as part of their functionality are already in AppStore.
- I strongly urge that the Nova Wallet team submit an Apple TSI to determine feasibility.
Worst case scenario, as you said on AAG session a few days ago, we would hope for sideloading law, or, if things are yet worse, on adding an add-on device we could develop later.
In reviewing my off the cuff speaking on AAG, I now understand how I may have miscommunicated. I should have clarified when Leemo spoke about the difficulty of publishing to the App Store.
While I do “hope” that sideloading will become available in the EU, it is not the basis of the Finsig SDK. As stated in my Tech Talk post and in my Realistic Expectations note.
It might be worth throwing a summary at the top to introduce some context? It’s quite hard to follow from the top…
Thank you for the feedback, Rich. I have revised the beginning of the post to explain.
Kirill from Kampela here, sorry for the delayed reply.
(Feel free to @-tag me in any further Kampela discussions on this forum, I’ll try to show up more timely next time.)
Indeed, we would need to utilize Core NFC Framework; at the same time, your payment-related links
The only thing our smartphone-side app is doing is interacting with the NDEF tag (that one in the “keychain token”). There is nothing I am aware of in the App Store review guidelines which requires any special handling for apps which are using NFCNDEFTag from CoreNFC — outside of the regular AppStore rules.
I’ve double-checked this just before typing this comment, both via Apple Forum search link you’ve provided, with Google and some AI-assisted search tools; the “no special requirement for the regular NDEF interaction from the foreground” seems to stand correct.
If you have any particular article you’re referring to when warning us — I would really appreciate the link, we’d better start preparing for this early.
But so far it seems that the rather broad scope of the NFC spec (and a rather vague language in Apple’s own review guidelines) seems to have sent you in the wrong direction, towards the “emulate the Visa/Mastercard NFC behaviour via the iPhone’s NFC chip” — the thing which is indeed explicitly prohibited by Apple guidelines (to protect their monopoly on the iPhone payment platform), and the thing which we never needed or intended to use for the Kampela companion app on iOS.
Hi Kirill, I will tag you moving forward. I have not been sent in the wrong direction; the red flag for me is “wallet” and “Core NFC”. For some background, I have been publishing to the App Store for over a decade and have had many interesting App Review experiences.
App Review is a universal pain point for App Store developers. Reviewers will sometimes cite a guideline by number and not provide further clarification. In your case, they could also simply cite that “Core NFC doesn’t support payment-related Application IDs.”
Also as a hardware companion app you’ll probably be subject to:
If features require an environment that is hard to replicate or require specific hardware, be prepared to provide a demo video or the hardware
The Ledger team must have faced something similar with the Nano X. I suggest also checking with them on how they navigated this process.
Well, I’m glad that we’re on the same page regarding the process quality (or lack thereof) of the Apple App Reviews.
Both me and Alex had been exposed to that when working on Polkadot Vault (then called Parity Signer) at Parity; and indeed, at certain points we’ve had to submit reviewers videos recording our app working.
Taking that experience into account, I’m still not convinced that what we’re facing here is worse risks than just a week or a two of delays and back-and-forth when it comes to updating our companion app in AppStore.
After all, Parity Signer used to do things much more suspicious for the reviewers, like straight away refusing to work if the airplane mode is not activated.
That was painful to pass those reviews, that’s true — but nothing in my experience suggests me that there’s any long-term, systemic risk for Kampela project here.
Yes, the App Review process is painful but I understand the reasoning. I respectfully disagree regarding the risk and wish your team the best of luck. I like the product idea and would be glad to be proven wrong.