41–50 of 69 posts
A more useful approach would be to open-source the AppHub framework so users can implement auto-updating themselves, and it would be harder for Apple to catch this.
If they change the terms of service to prevent hot loading app updates via JavaScriptCore they're going to isolate a lot of developers, since so much cool stuff is being developed around JavaScriptCore right now. The rnplay playground app that's currently in the App Store dynamically loads entire apps onto your phone to play around with -- it's so cool, why block things like that from existing?
If they do nothing, it's clear a rogue app store distribution ecosystem is going to evolve (case in point ^) which seems like a sub-optimal outcome for everyone.
Isn't the only eventuality for Apple to change their app store approval process to allow dynamic updates? I mean it's obviously better for developers, and probably ultimately better for end users as well. I just don't see any way around it with the momentum writing iOS apps in Javascript has right now.
Earlier quoted context omitted.
Oh, so you're only going to support WebPack? That's disappointing.
No one said anything about webpack. If you have another async module loading syntax you'd prefer I'm sure we'd be happy to look at it.
I see that lasting almost three weeks before Apple shut it down (assuming anyone uses it...)
Apple does allow it as long as they are only pushing html / js. IPA changes would still need to go though Apple. From Apples guidelines: https://developer.apple.com/programs/ios/information/iOS_Pro... "The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Applicatio…
Earlier quoted context omitted.
No one said anything about webpack. If you have another async module loading syntax you'd prefer I'm sure we'd be happy to look at it.
Webpack is the only loader that does require.ensure to my knowledge. To answer your question; there's also System.import() (SystemJS) and require([]) (any AMD loader like requirejs) that are async module loading.
Earlier quoted context omitted.
This: "Stop waiting weeks for Apple to review your app. Just add our iOS framework and start pushing updates." says otherwise.
The key verbiage is "release" vs "updates." You still have to go through the initial App Store Release process initially. After that, using this framework you can push updates directly, rather than waiting the requisite 5 business days[1]. As an app developer, being able to push updates (read: bug fixes) immediately is a blessing--we live and die by our reviews, and a bad update can cause an avalanche of negative rev…
Earlier quoted context omitted.
Yep, "feature flipping" can lead to app rejections and getting booted from the store. * If the AppHub founders think this is a real danger, then you'd expect bold and strenuous documentation. * But, I wonder if the AppHub authors believe that people should ignore this rule, because practically speaking it's hard to get caught. They wouldn't say so, of course, because encouraging people to break Apple ToS is illegal.
Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.
Earlier quoted context omitted.
Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.
It feels like it might be some sort of crime specifically to misrepresent your product as being capable of X and sell it to people who you know will try to use it for X, when X is disallowed by the ToS of the platform. Con-artistry of a sort.
And actually, merely adding features doesn't seem to be forbidden as long as the features you add are not "inconsistent with the intended and advertised purpose of the Application as submitted to the App Store"
So let's say you release a file manager and later, surprise! It's also a SNES emulator! Well, then yes, I can see that against the TOS. But if you're just making improvements to your app, I don't see a problem.
And this is why we can't have nice things. Someone is going to submit a React Native app to the App Store, use this bullshit to bypass the update review, and either use it to steal information of a user, or post dick pics all over the app.
Yes, but if AppHub didn't build this, someone else would. Just because something isn't the "safest" idea doesn't mean we shouldn't stop experimenting. Also, how would this make it easier to steal user information or share your stash of dick pics? Sounds like a lot of FUD to me.
What exactly does that mean? My statement doesn't change just because someone else made it.
Earlier quoted context omitted.
Yep, "feature flipping" can lead to app rejections and getting booted from the store. * If the AppHub founders think this is a real danger, then you'd expect bold and strenuous documentation. * But, I wonder if the AppHub authors believe that people should ignore this rule, because practically speaking it's hard to get caught. They wouldn't say so, of course, because encouraging people to break Apple ToS is illegal.
Is it illegal? I would expect it to maybe break the ToS or something contract related, not be criminal.
It was just a hypothetical though. AppHub has plenty of legit use cases under Apple rules, and it's probably not all that dangerous even if you "mis-use" it slightly. AppHub would have to explicitly encourage people to break the rule to run afoul, or Apple would have to organically notice a bunch of apps doing a bunch of outlandish feature flipping.