8 ms·

CodePush by Microsoft

266 points by onra87 11y ago

stephenr 11y ago
Doesn't this go against Apple's rules? Seems to me it's effectively bypassing their checks - a developer can release v1.0.0 to the app store, never again update it, and push updates via this?
- ckluis 11y ago
  FAQ - http://microsoft.github.io/code-push/faq/index.html http://microsoft.github.io/code-push/faq/index.html According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process. Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement. (copy pasted directly from codepush site)
- deleted 11y ago
  [deleted]
- bwhitty 11y ago
  They already have blessed hot-code pushes; see Meteor: http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile
joshuahornby 11y ago
This can also be done in React with out the need of a 3rd party deploy tool as such. http://joshhornby.co.uk/blog/react-native-and-continuous-deployment/ http://joshhornby.co.uk/blog/react-native-and-continuous-dep...
drdaeman 11y ago
From an user perspective, that's awful. [Edit: if there's no way to force all updates to be manually confirmed, seems that suggested workflow is that they are: https://news.ycombinator.com/item?id=10517193 https://news.ycombinator.com/item?id=10517193] Seriously, I absolutely hate when apps change their behavior or looks without explicitly asking me for a permission (and so I can make a backup to revert if I don't fancy what goes on).
- isthmus_ 11y ago
  I'm actually okay with this. It's not my app. The designers know more about UX than I do. It's not like you can change device permissions through this. I've been learning digital UI's all my life, I can handle things shifting around and changing features. I'm happy with anything that gives devs more agency over how much they can improve their product. My only worry is that it might be too easy to push updates, so less testing may go into updates because the threshold to do so is low. Kind of like what happened to video games once you could patch things.
  - lostintangent 11y ago
    We definitely don't want to encourage "abusing" the service by producing poorly tested updates. We're planning to do some work/docs to help incorporating a CodePush deployment into a CI workflow that can choose to rely on tests to ensure quality, and also use multiple environments to be able to manually test an update in staging before pushing it out to users.
- recursive 11y ago
  You must hate Chrome.
  - drdaeman 11y ago
    I prefer Firefox (although it has its share of issues), but generally GNU/Linux distributions come with Chromium, with ripped-out auto-update mechanisms in favor of "classic" updates through a package management system. Anecdotally, my dad, which happened to run Chrome on Windows, didn't fancy most of visible changes.
pmalynin 11y ago
Or just use Meteor.
vyrotek 11y ago
Perfect! I wish we had this 2 years ago when we first started with Cordova. We've since "hacked" our own similar system to dynamically load cordova content into our mobile app.
- ptarjan 11y ago
  Could you open source your code?
bmy78 11y ago
Wow, a Microsoft product that doesn't reference other MS products! I'm so used to the 'click a button' in Visual Studio to publish your C# / ASP.NET code to access SQL Server in the cloud supported by Azure.
- lostintangent 11y ago
  We have that button on our backlog! ;)
- blazespin 11y ago
  Visual studio is pretty awesome these days. Try it out
  - JBiserkov 11y ago
    See also Visual Studio Code: https://code.visualstudio.com https://code.visualstudio.com I love and hate that name at the same time :-)
    - cableshaft 11y ago
      I use VSCode for my python scripting on my super cheap and lightweight laptop I got for my outings to Starbucks, and VSCode works pretty darn well for that. I also like the integrated support for Git.
hoodoof 11y ago
It's a strange thing that this targets react-native react-native, despite one of its core values probably being cross platform support, is extremely disinterested in providing anything but OSX support. Check out the wording from their site: https://facebook.github.io/react-native/docs/linux-windows-support.html https://facebook.github.io/react-native/docs/linux-windows-s... ""As React Native on iOS requires a Mac and most of the engineers at Facebook and contributors use Macs, support for OS X is a top priority. However, we would like to support developers using Linux and Windows too. We believe we'll get the best Linux and Windows support from people using these operating systems on a daily basis. Therefore, Linux and Windows support for the development environment is an ongoing community responsibility."" Which is to say "At Facebook we like Macs, we have Macs. Maybe someone else who likes Windows will build for Windows and Linux. Go ask them to do it." I was recently looking for a cross platform development environment and was very interested in react-native but I completely lost interest after reading about their attitude to non-OSX support.
- jaegerpicker 11y ago
  I'm not sure why you think that Facebook should support other platforms? It's open source and free of charge to you. Doesn't it make sense that they are going to support only the platform that they use and are mostly interested in?
- spicyj 11y ago
  (I work on React.) Facebook works on tools that help Facebook. We like to give back to the community whenever we can. Unlike most other platforms, our end goal is not building and making tools or technology. Instead, we build whatever helps us make better products. This means that (IMO) we end up with higher-quality tools. It also means that we focus on the use cases that are important to us which occasionally differs from what's most important to the community. (Though even if you look at what the community has voted for, Linux and Windows support doesn't even make the list: https://productpains.com/product/react-native/?tab=top&. https://productpains.com/product/react-native/?tab=top&.) Since most developers at FB use Macs, that's what we supported first. If there's community interest in React Native running on Windows and Linux (and there is), we'll happily take pull requests that add support, and I see no reason why we can't make sure the support doesn't regress after it's merged. I'm not sure why this strategy is upsetting to you. As a point of comparison, Rust's Windows support lagged behind for many years and what it did have was community-supported. Now, Windows has caught up and it will remain a first-class target for them. I expect React Native to end up in the same place within the next few months.
a_soncodi 11y ago
This is great. Between updates/hydration and browser APIs like web push notifications, camera, geo etc.. the app stores are just glorified CDNs. Building 'natively' for these platforms offers few advantages, but adds overhead, deployment delays, and vendor-specific concerns. Choosing to release on an app store should be a config setting, not a business model.
- blazespin 11y ago
  Not on iOS until can you install from something other than the App Store. You still have to get a cert and you can still lose it.
michaelchum 11y ago
I wonder how Apple is going to react to this. This basically allows developers to issue app updates and bypass the Apple App Store verification process.
netinstructions 11y ago
If you're looking to update React Native apps on iOS in a similar fashion (without going through the Apple Store), AppHub[1][2] looks to be tackling this as well. Not affiliated, just saw it mentioned in one of the React Native PRs[3] to help enable some of the functionality. [1]https://apphub.io/ https://apphub.io/ [2]https://github.com/AppHubPlatform/apphub-ios https://github.com/AppHubPlatform/apphub-ios [3]https://github.com/facebook/react-native/pull/3189 https://github.com/facebook/react-native/pull/3189
- kookiekrak 11y ago
  there's also a cool company called Primer that does the same for mobile onboarding screens on iOS https://goprimer.com https://goprimer.com
- chambo622 11y ago
  Interesting, it looks like AppHub gets a bit pricey. It's not hard to build a basic version of this from scratch (just a basic update service running on a Droplet, and a routine in the app to check for new js bundles on launch and fall back to the last known good bundle or the shipped bundle in case of a failure). It's an interesting niche but I'm not convinced of the value at these price points.
neves 11y ago
Wow! I want to see how Apple and Google will treat this hole in the wall of their walled gardens. Updates that don't go through their app stores.
- ChuckMcM 11y ago
  Apple will no doubt disapprove any App that uses this. Google has always been "ok" with apps that install directly so presumably it won't really bother them. Obviously Microsoft will support it in Apps they sell through the Windows app store. Given the stuff you can change its pretty clear you could completely change the user experience. So yes, it would be a pretty big "hole" in the app experience management policy.
  - blazespin 11y ago
    Apple has already given permission to update anything that uses HTML/JAVASCRIPT. Which react native does.
  - kcbanner 11y ago
    Wrong. Many apps that have been in the app store for years use this technique. Apple in fact explicitly allows this.
- bwhitty 11y ago
  Apple at least already allows this for Javascript based apps, particularly Meteor as an example: http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile
  - madeofpalk 11y ago
    When talking about Apple, I find it easier to think of just two state for apps (that use this): Rejected and not-yet-rejected. Also, there aren't App Store _rules_, they're just guidelines. Apple is still able to pick and choose that they enforce and reject apps for their own reasons. For this particular issue, Apple allows apps to dynamically download Javascript and other web tech (in order for web browsers to work), and they explicitly mention that they're not into you pushing big updates: provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store. As always, the App Review Team gets the final say on a case-by-case basis for whether you'll get through or not.
davej 11y ago
I wonder could this potentially be used with Electron or nw.js?
- lostintangent 11y ago
  We've only just initially added clients for Cordova and React Native, but we plan (and would love to work the community) to build clients for other platforms, so dynamic updates of code and/or content could be easier.
sb8244 11y ago
Ionic has a product called Deploy which is currently in Alpha (production use not recommended). They do a pretty good job explaining binary versioning, which is eluded too with CodePush but not in detail. Basically, it might seem too good to be true, and it is. You can push small changes up to the app store, but still have to re-submit for any binary changes. http://docs.ionic.io/docs/deploy-binary-versioning http://docs.ionic.io/docs/deploy-binary-versioning
- lostintangent 11y ago
  Thanks for bringing this up! We definitely need to do a better job raising this point in our docs. That said, I hope this limitation doesn't make it "too good to be true". From the many Cordova/React Native devs we've spoken with, being able to update JavaScript, CSS, images and other content assets, enables handling lots of fixes/updates, before hitting the need to update through a store. We look forward to hearing more feedback on this topic though!
  - sb8244 11y ago
    Good point. Too good to be true referring to only dealing with the App Store once.
    - lostintangent 11y ago
      Yep that's true. I'll add this point to our docs so it doesn't seem like we're trying to manipulate the value of the service. Thanks for the feedback!
sudhirj 11y ago
Was reading somewhere that you're free to do on the fly updates of any interpreted code - so JavaScript is fine. Only compiled code can't be updated on the fly. And in react native only the main framework is compiled, with the actual application running in a JS interpreter. So unless we upgrade the RN version, or start using a new SDK etc there will never be a reason to go through the App Store. All interpreted code is sandboxed anyway, so there's no security risks involved.
- lostintangent 11y ago
  This compelling opportunity is what made us decide to build CodePush!
  - blazespin 11y ago
    Yes, been waiting for this for quite awhile. Great job guys. Msft is definitely building exciting stuff these days. Hope it's converting into revenue at some point.
    - jonnyscholes 11y ago
      Great job *team. :)
      - Cthulhu_ 11y ago
        Guys is generally used gender-ambigously. :)
  - bsimpson 11y ago
    That landing page is the most hipster thing I've ever seen come out of Microsoft. It's hard to believe that the same company that cursed the world with IE 6 just released an open-source accessory for a Facebook platform and signed it "with <3 from Redmond."
    - lostintangent 11y ago
sudo_bang_bang 11y ago
I've been looking at trying out AppHub https://apphub.io/ https://apphub.io/, which is comparable to CodePush. I'll have to try this. As it is, both are definitely useful for better handling upgrade process with users. A couple drawbacks with mobile apps are that it's harder to hotfix errors, and you sometimes have to support older APIs for longer. With a web app, a user can visit the site and the entire app bundle can be downloaded after a cache bust.
- lostintangent 11y ago
  As a team of web devs who love mobile, we definitely wanted to help bring as much of this kind of update experience to client apps as possible. I look forward to hearing any feedback you may have after giving us a try :)
enos_feedler 11y ago
I wonder if Apple will ever release an API that allows apps to do this kind of hot updating natively. I could imagine breaking up an application into multiple containers and then orchestrating some kind of update process by calling out to the system APIs. At least then it would not compromise the security of App Store / Test flight. As more meta-data was extracted/tagged with these containers you could imagine Apple reviewers start to care less about the code inside the container and more the interfaces (does it use health kit? apple pay? etc) and whether they are likely to be reviewed again. Could also look at size of binaries changes and things like that, or perhaps at LLVM byte code level for more detail.
z3t4 11y ago
The Cardova tech is very exiting and advancing fast. Today it's almost as easy as making a web app. Your users need to hack their OS to be able to use your app though ... OS's need to find a way to contain apps that don't need full system access. Maybe by higher level user-mode so that apps need to ask for permission before using API's.
vbezhenar 11y ago
That's kind of double-standards for Apple. I can update JavaScript without approving, but I have to wait for days or weeks to update native app.

266 points by onra87 11y ago

Doesn't this go against Apple's rules? Seems to me it's effectively bypassing their checks - a developer can release v1.0.0 to the app store, never again update it, and push updates via this?

ckluis 11y ago
FAQ - http://microsoft.github.io/code-push/faq/index.html http://microsoft.github.io/code-push/faq/index.html According to section 3.3.2 of Apple’s developer agreement, as long as you are using the CodePush service to release bug fixes and improvements/features that maintain the app’s original/presented purpose (i.e. don’t CodePush a calculator into a first-person shooter), then you will be fine, and your users will be happy. In order to provide a tangible example, our team published a (pretty cheesy!) CodePush-ified game to the Google Play Store and Apple App Store, and had no problems getting it through the review process. Because Cordova apps are executed within a WebView, and React Native apps are executed within JavaScriptCore, from a technology perspective, these runtimes are unique in their ability to leverage dynamic code downloads according to the aforementioned Apple developer agreement. (copy pasted directly from codepush site)
deleted 11y ago
[deleted]
bwhitty 11y ago
They already have blessed hot-code pushes; see Meteor: http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile

joshuahornby 11y ago

This can also be done in React with out the need of a 3rd party deploy tool as such. http://joshhornby.co.uk/blog/react-native-and-continuous-deployment/ http://joshhornby.co.uk/blog/react-native-and-continuous-dep...

drdaeman 11y ago

From an user perspective, that's awful. [Edit: if there's no way to force all updates to be manually confirmed, seems that suggested workflow is that they are: https://news.ycombinator.com/item?id=10517193 https://news.ycombinator.com/item?id=10517193] Seriously, I absolutely hate when apps change their behavior or looks without explicitly asking me for a permission (and so I can make a backup to revert if I don't fancy what goes on).

isthmus_ 11y ago
I'm actually okay with this. It's not my app. The designers know more about UX than I do. It's not like you can change device permissions through this. I've been learning digital UI's all my life, I can handle things shifting around and changing features. I'm happy with anything that gives devs more agency over how much they can improve their product. My only worry is that it might be too easy to push updates, so less testing may go into updates because the threshold to do so is low. Kind of like what happened to video games once you could patch things.
- lostintangent 11y ago
  We definitely don't want to encourage "abusing" the service by producing poorly tested updates. We're planning to do some work/docs to help incorporating a CodePush deployment into a CI workflow that can choose to rely on tests to ensure quality, and also use multiple environments to be able to manually test an update in staging before pushing it out to users.
recursive 11y ago
You must hate Chrome.
- drdaeman 11y ago
  I prefer Firefox (although it has its share of issues), but generally GNU/Linux distributions come with Chromium, with ripped-out auto-update mechanisms in favor of "classic" updates through a package management system. Anecdotally, my dad, which happened to run Chrome on Windows, didn't fancy most of visible changes.

pmalynin 11y ago

Or just use Meteor.

vyrotek 11y ago

Perfect! I wish we had this 2 years ago when we first started with Cordova. We've since "hacked" our own similar system to dynamically load cordova content into our mobile app.

ptarjan 11y ago
Could you open source your code?

bmy78 11y ago

Wow, a Microsoft product that doesn't reference other MS products! I'm so used to the 'click a button' in Visual Studio to publish your C# / ASP.NET code to access SQL Server in the cloud supported by Azure.

lostintangent 11y ago
We have that button on our backlog! ;)
blazespin 11y ago
Visual studio is pretty awesome these days. Try it out
- JBiserkov 11y ago
  See also Visual Studio Code: https://code.visualstudio.com https://code.visualstudio.com I love and hate that name at the same time :-)
  - cableshaft 11y ago
    I use VSCode for my python scripting on my super cheap and lightweight laptop I got for my outings to Starbucks, and VSCode works pretty darn well for that. I also like the integrated support for Git.

hoodoof 11y ago

It's a strange thing that this targets react-native react-native, despite one of its core values probably being cross platform support, is extremely disinterested in providing anything but OSX support. Check out the wording from their site: https://facebook.github.io/react-native/docs/linux-windows-support.html https://facebook.github.io/react-native/docs/linux-windows-s... ""As React Native on iOS requires a Mac and most of the engineers at Facebook and contributors use Macs, support for OS X is a top priority. However, we would like to support developers using Linux and Windows too. We believe we'll get the best Linux and Windows support from people using these operating systems on a daily basis. Therefore, Linux and Windows support for the development environment is an ongoing community responsibility."" Which is to say "At Facebook we like Macs, we have Macs. Maybe someone else who likes Windows will build for Windows and Linux. Go ask them to do it." I was recently looking for a cross platform development environment and was very interested in react-native but I completely lost interest after reading about their attitude to non-OSX support.

jaegerpicker 11y ago
I'm not sure why you think that Facebook should support other platforms? It's open source and free of charge to you. Doesn't it make sense that they are going to support only the platform that they use and are mostly interested in?
spicyj 11y ago
(I work on React.) Facebook works on tools that help Facebook. We like to give back to the community whenever we can. Unlike most other platforms, our end goal is not building and making tools or technology. Instead, we build whatever helps us make better products. This means that (IMO) we end up with higher-quality tools. It also means that we focus on the use cases that are important to us which occasionally differs from what's most important to the community. (Though even if you look at what the community has voted for, Linux and Windows support doesn't even make the list: https://productpains.com/product/react-native/?tab=top&. https://productpains.com/product/react-native/?tab=top&.) Since most developers at FB use Macs, that's what we supported first. If there's community interest in React Native running on Windows and Linux (and there is), we'll happily take pull requests that add support, and I see no reason why we can't make sure the support doesn't regress after it's merged. I'm not sure why this strategy is upsetting to you. As a point of comparison, Rust's Windows support lagged behind for many years and what it did have was community-supported. Now, Windows has caught up and it will remain a first-class target for them. I expect React Native to end up in the same place within the next few months.

a_soncodi 11y ago

This is great. Between updates/hydration and browser APIs like web push notifications, camera, geo etc.. the app stores are just glorified CDNs. Building 'natively' for these platforms offers few advantages, but adds overhead, deployment delays, and vendor-specific concerns. Choosing to release on an app store should be a config setting, not a business model.

blazespin 11y ago
Not on iOS until can you install from something other than the App Store. You still have to get a cert and you can still lose it.

michaelchum 11y ago

I wonder how Apple is going to react to this. This basically allows developers to issue app updates and bypass the Apple App Store verification process.

netinstructions 11y ago

If you're looking to update React Native apps on iOS in a similar fashion (without going through the Apple Store), AppHub[1][2] looks to be tackling this as well. Not affiliated, just saw it mentioned in one of the React Native PRs[3] to help enable some of the functionality. [1]https://apphub.io/ https://apphub.io/ [2]https://github.com/AppHubPlatform/apphub-ios https://github.com/AppHubPlatform/apphub-ios [3]https://github.com/facebook/react-native/pull/3189 https://github.com/facebook/react-native/pull/3189

kookiekrak 11y ago
there's also a cool company called Primer that does the same for mobile onboarding screens on iOS https://goprimer.com https://goprimer.com
chambo622 11y ago
Interesting, it looks like AppHub gets a bit pricey. It's not hard to build a basic version of this from scratch (just a basic update service running on a Droplet, and a routine in the app to check for new js bundles on launch and fall back to the last known good bundle or the shipped bundle in case of a failure). It's an interesting niche but I'm not convinced of the value at these price points.

neves 11y ago

Wow! I want to see how Apple and Google will treat this hole in the wall of their walled gardens. Updates that don't go through their app stores.

ChuckMcM 11y ago
Apple will no doubt disapprove any App that uses this. Google has always been "ok" with apps that install directly so presumably it won't really bother them. Obviously Microsoft will support it in Apps they sell through the Windows app store. Given the stuff you can change its pretty clear you could completely change the user experience. So yes, it would be a pretty big "hole" in the app experience management policy.
- blazespin 11y ago
  Apple has already given permission to update anything that uses HTML/JAVASCRIPT. Which react native does.
- kcbanner 11y ago
  Wrong. Many apps that have been in the app store for years use this technique. Apple in fact explicitly allows this.
bwhitty 11y ago
Apple at least already allows this for Javascript based apps, particularly Meteor as an example: http://info.meteor.com/blog/apple-hot-code-push-mobile http://info.meteor.com/blog/apple-hot-code-push-mobile
- madeofpalk 11y ago
  When talking about Apple, I find it easier to think of just two state for apps (that use this): Rejected and not-yet-rejected. Also, there aren't App Store _rules_, they're just guidelines. Apple is still able to pick and choose that they enforce and reject apps for their own reasons. For this particular issue, Apple allows apps to dynamically download Javascript and other web tech (in order for web browsers to work), and they explicitly mention that they're not into you pushing big updates: provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store. As always, the App Review Team gets the final say on a case-by-case basis for whether you'll get through or not.

davej 11y ago

I wonder could this potentially be used with Electron or nw.js?

lostintangent 11y ago
We've only just initially added clients for Cordova and React Native, but we plan (and would love to work the community) to build clients for other platforms, so dynamic updates of code and/or content could be easier.

sb8244 11y ago

Ionic has a product called Deploy which is currently in Alpha (production use not recommended). They do a pretty good job explaining binary versioning, which is eluded too with CodePush but not in detail. Basically, it might seem too good to be true, and it is. You can push small changes up to the app store, but still have to re-submit for any binary changes. http://docs.ionic.io/docs/deploy-binary-versioning http://docs.ionic.io/docs/deploy-binary-versioning

lostintangent 11y ago
Thanks for bringing this up! We definitely need to do a better job raising this point in our docs. That said, I hope this limitation doesn't make it "too good to be true". From the many Cordova/React Native devs we've spoken with, being able to update JavaScript, CSS, images and other content assets, enables handling lots of fixes/updates, before hitting the need to update through a store. We look forward to hearing more feedback on this topic though!
- sb8244 11y ago
  Good point. Too good to be true referring to only dealing with the App Store once.
  - lostintangent 11y ago
    Yep that's true. I'll add this point to our docs so it doesn't seem like we're trying to manipulate the value of the service. Thanks for the feedback!

sudhirj 11y ago

Was reading somewhere that you're free to do on the fly updates of any interpreted code - so JavaScript is fine. Only compiled code can't be updated on the fly. And in react native only the main framework is compiled, with the actual application running in a JS interpreter. So unless we upgrade the RN version, or start using a new SDK etc there will never be a reason to go through the App Store. All interpreted code is sandboxed anyway, so there's no security risks involved.

lostintangent 11y ago
This compelling opportunity is what made us decide to build CodePush!
- blazespin 11y ago
  Yes, been waiting for this for quite awhile. Great job guys. Msft is definitely building exciting stuff these days. Hope it's converting into revenue at some point.
  - jonnyscholes 11y ago
    Great job *team. :)
    - Cthulhu_ 11y ago
      Guys is generally used gender-ambigously. :)
- bsimpson 11y ago
  That landing page is the most hipster thing I've ever seen come out of Microsoft. It's hard to believe that the same company that cursed the world with IE 6 just released an open-source accessory for a Facebook platform and signed it "with <3 from Redmond."
  - lostintangent 11y ago

sudo_bang_bang 11y ago

I've been looking at trying out AppHub https://apphub.io/ https://apphub.io/, which is comparable to CodePush. I'll have to try this. As it is, both are definitely useful for better handling upgrade process with users. A couple drawbacks with mobile apps are that it's harder to hotfix errors, and you sometimes have to support older APIs for longer. With a web app, a user can visit the site and the entire app bundle can be downloaded after a cache bust.

lostintangent 11y ago
As a team of web devs who love mobile, we definitely wanted to help bring as much of this kind of update experience to client apps as possible. I look forward to hearing any feedback you may have after giving us a try :)

enos_feedler 11y ago

I wonder if Apple will ever release an API that allows apps to do this kind of hot updating natively. I could imagine breaking up an application into multiple containers and then orchestrating some kind of update process by calling out to the system APIs. At least then it would not compromise the security of App Store / Test flight. As more meta-data was extracted/tagged with these containers you could imagine Apple reviewers start to care less about the code inside the container and more the interfaces (does it use health kit? apple pay? etc) and whether they are likely to be reviewed again. Could also look at size of binaries changes and things like that, or perhaps at LLVM byte code level for more detail.

z3t4 11y ago

The Cardova tech is very exiting and advancing fast. Today it's almost as easy as making a web app. Your users need to hack their OS to be able to use your app though ... OS's need to find a way to contain apps that don't need full system access. Maybe by higher level user-mode so that apps need to ask for permission before using API's.

vbezhenar 11y ago

That's kind of double-standards for Apple. I can update JavaScript without approving, but I have to wait for days or weeks to update native app.