Hacker News Reader

Comment by joshstrange | Hacker News Reader

I'm not sure this article has the slam dunk it thinks it does. Those aren't "apps" they are at best "web apps". They use a JS framework and some special markup from what I can tell. In this sense WeChat is more akin to a web browser than having multiple "apps" inside it.

> Since these are “apps within an app”, many of these mini-programs are flouting the App Store rules since they were not downloaded from the App Store.

I mean Drafts has the ability to download actions (not sure if that is the right term) which are JS that run inside the app. I think this is fine and doesn't skirt any rules, I don't see why WeChat is all that different.

All that said, of course Apple is going to make exceptions for WeChat the same way it makes various concessions to other countries.

View on HN

Regardless of its implementation, everything in the app is subject to the rule as long as it's distributed in the App Store. In fact, Apple tried to enforce the same rule on WeChat multiple times but gave up since it practically means giving up the entire China market.

> Regardless of its implementation

Implementation is very much part of the rules. Apps cannot download and execute external code… unless it’s JavaScript in a browser.

Nothing in the article suggests that WeChat apps are not plain websites, so it seems that they don’t know the rules nor the alleged rule breaker’s technical side.

I wouldn’t exclude that WeChat really does get a pass from Apple, but the article does not clarify this important point.

A lot of these superapp mini-app can be just a link. It can be an in-app browser with static link to a college level javascript games page, maybe with credit purchase through native code going back and forth with URL parameters and callbacks. If you're doing superapps you're likely going for a janky bag full of features so that'll be fine.

I thought Apple disallowed apps from downloading things that were executable. A team I was on got rejected for this in 2015 or so. We were using Ionic to make a WebView based app for a news station. We wanted some of the css and js to be loaded from the internet so we could change various things without needing an official app update.

We were told to we could fetch news story data from an api, and get back json/xml/etc, but not JS and CSS files.

i don't know what you did, but see this discussion here: https://stackoverflow.com/questions/23247809/does-apple-reje...

though it's not really clear to me what it means to change your app's functionality in a way that would not be appropriate for an App Store product

I know of multiple apps that have that ability and I've personally shipped 10+ cross-platform apps built on Quasar+Vue+Capacitor and Ionic+Angular+Cordova/Capacitor and a few have had the ability to remotely update the code (just the JS/HTML/CSS) and they have all been approved. I am interested in the exact way the rejection was worded. IIRC their dev agreement had an exception, at one point, to the "no downloading executable code" rule, it said that using downloaded code in JavascriptCore was allowed. Apple doesn't seem to approve of remote updating but they seem to turn a blind eye to it, I would assume most big companies that use these cross-platform tools like this have a way to remotely update the code (JS/HTML/CSS).

I totally believe they rejected your app though, App Store review is pretty bad. I mean at least they are _way_ faster now but it's reviewer roulette for sure. I've been dinged for things that aren't even in the App Store dev agreement, they were in some other document. Even worse the reviewer told me I needed to change my wording when requesting a permission, the problem? She wanted me to change text I don't control in the permissions dialog. I explained that I only had control over the single string in quotes but she told me I was wrong (I got through on the next review). The inconsistency in the review process is maddening and so much of it is reading the tea leaves of what they actually want and what is allowed. I mean, we all know it's against the rules to send advertising/marketing push notifications right? Right? That _never_ happens in the App Store... Make whatever rules you want but dear god please enforce them consistently and change/remove a rule if you've decided to not enforce it.

It's been a while but I think it was because it was considered a remote update mechanism. We planned to keep it limited to small layout fixes and such but in theory we could have changed everything about the app (it had news available in like 15 languages and there was always some new issue related to right-to-left, or CJK font stuff or etc. We didn't want to make all users have a new update just because Cyrillic needed some layout change or something).

But yeah it also probably was partly due to reviewer roulette. I've experienced the same on other apps, things that have been in the app for a year can suddenly get it rejected without a corresponding rules change from Apple. Just different interpretations of our code by a new reviewer.

In this case we decided to just remove that feature and re-publish.

> But yeah it also probably was partly due to reviewer roulette. I've experienced the same on other apps, things that have been in the app for a year can suddenly get it rejected without a corresponding rules change from Apple. Just different interpretations of our code by a new reviewer.

Been there. The best is when I have an app that has actually been released on multiple other accounts (white label app) and then a reviewer wants to say it's all wrong and reject it. I the worst thing that's happened to me is when they dinged me for a soft permission prompt (asking the user before throwing the one-time-only system dialog), I removed it since I needed to get the update out (it wasn't related to this at all of course), then they started nit-picking and not only were they wrong in a lot of the cases but they were making me do like 1-2 word changes to permission prompts to make them more specific. I had no clue how many new things they'd come up with for each submission, we went back and forth a few times before it finally got through, I just bumped the build number and resubmitted.

I've never actually developed a mini program, but worked on projects with our china teams to develop some activation for our brand on WeChat.

What I understand is that a mini program needs to be "packaged" and shipped to WeChat as a bundle. The size of the bundle is relatively small. (~10mb ?)

Of course you can load some content from outside, not everything is within those 10mb, but I think it's still relatively limited. Calling it apps within apps is a stretch.

It’s really dependent on what reviewer you get. I develop a coding app for iPad (Codea) and for the longest time was not allowed to let users share their code in any form. I asked the reviewer “but they can just copy and paste it?” And the reviewer said “that is ok.”

In the end, it was down to whether it _looked like_ your app was downloading executable code more than whether it actually did. Reviewers are non-technical, and when the policy is technical they often make an inference that may be incorrect — however they will not budge on that without consulting actual engineers further up the chain, which can take weeks

They have become a lot more relaxed about this policy in the last five years or so (ever since Shortcuts)

Apple bans alternative web browsers too... so..

I assume you are replying to this part?

> WeChat is more akin to a web browser than having multiple "apps" inside it

>> Apple bans alternative web browsers too... so..

If they use a different browser engine they are currently banned but you can wrap Safari/webkit like every browser app on iOS does and provide different chrome/features. WeChat isn't embedding a different rendering engine, just using webkit.

>> I mean Drafts has the ability to download actions (not sure if that is the right term) which are JS that run inside the app. I think this is fine and doesn't skirt any rules,

I'm not familiar with that particular app but if that happens it's not fine and it seems to get a pass from Apple. The apps are not allowed to download executable code. You have to bundle it all in the app.

That's not exclusive to that app. Being able to update the app without going through the App Store was one of the big selling points of React Native a few years back. Apps are not allowed to download native code, however.

That's ...not a feature of React Native. It's possible to reload the app's content on code change, but this very clearly intended for development only.

You’re describing fast refresh, the parent is talking about codepush. The whole point of CodePush is definitely to update the app without going through the store. It downloads a JS bundle (which is usually most of the app functionalities) and executes it.

You cannot download and execute native code on iOS, the sandbox prevents it. Memory protection ensures that pages marked as data cannot be executed

There is a special entitlement to allow some Apple apps and frameworks to do this — Apple’s JavaScriptCore can do JIT, which requires executing data pages. Similarly, Swift Playgrounds can compile to native code and execute that code

So, for example, you could ship a C compiler on iOS and it would compile perfectly valid binaries, but you would never be able to execute those binaries natively without code-signing them and deploying them in an Apple sanctioned way, which you cannot do on-device (except with the above mentioned exceptions)

> Apple’s JavaScriptCore can do JIT

Only for Safari or if you use a WKWebView, otherwise if you use JavascriptCore yourself on iOS, JIT is disabled and quite slow. On macOS it’s enabled.

Reply on news.ycombinator.com