4 ms·
Nice, or rather: nice, as long as it can be wrapped in a good cross platform layer (which means that it boils down to website repackaged with the platform's out
by usrusr 3y ago
Nice, or rather: nice, as long as it can be wrapped in a good cross platform layer (which means that it boils down to website repackaged with the platform's out-of-browser payment mechanism).
I only know the supposed Android equivalent from the inside, and while I believe that it could be used for the "browser plus platform payment" pattern, it's main focus seems to be incremental delivery of large apps. That is a hard problem given the circumstances of the Android build process and their solution seems kind of stuck in those last 20%. Fortunately incremental is not really related to the temporary use case (if stuff like media in the menu is dealt with by the platform browser), but the attention given to (andvTwitter by) the much harder problem of incremental delivery isn't exactly helpful when that's not what you want to use it for.
- dwaite 3y ago> as long as it can be wrapped in a good cross platform layer (which means that it boils down to website repackaged with the platform's out-of-browser payment mechanism). If you are trying to build a cross-platform application using some large framework, it will likely be too large. There is an upper size limit of 10 MB. Once you move to platform specific tech, you can do things like grab just the image assets needed for a particular device dot pitch and resolution. Hypothetically you could use those in a WKWebView to render HTML content, although I do not know of existing efforts to do so. If it is more than four screens I would expect the technology to be a bad fit. If you could figure out maintenance of menu changes, you'd likely be better off just using native libraries (similarly, sometimes its better to just use PHP and inline javascript)