FYI you can use ffmpeg to encode gif as h264/h265 mp4 videos of varying quality or convert to webm which can be played from an img tag, all of which will be orders of magnitude smaller.
That’s still very unreasonably large and is going to cause real problems for some users, though not as many (and is still going to be uselessly slow to load for many—much of the world, including where large numbers of developers, even SwiftUI developers, are, doesn’t have multi-megabit-per-second speeds). Look, even 20MB is too large. Please, I beg you, just don’t put any GIFs on that page: just make it clear that it’s a video, e.g. by overlaying a circled play icon on the image and making it a link to the relevant video on YouTube.
Interesting, via iOS safari the page was quick to load and scrolled smoothly, no noticeable performance issue (excepting the payload size is excessive).
Worked fine for me on AOSP8 with Iceweasel on Honor 9 too, albeit on ac wireless with 400Mbps connection (at least I didn't notice any slowdowns, and this is hardly top of the line hw or sw).
Ouch ouch ouch ouch ouch. Flagged the submission for this reason, it’s going to cause severe problems for lots of people, and being GIFs and so enormous they don’t even load well (when I start loading even the first GIF by itself, it spends a lot of its time loading at below one frame per second). The GIFs should be removed urgently and replaced with static images and links to videos.
I've flagged the title; it is incredibly poor etiquette to sneak half a gig in downloads on a user, especially when demonstrating something for mobile!
No, don’t put it in the title, just fix the page. A page being even 100MB would be wildly unacceptable, let alone 450MB.
The really quick fix is just to replace the images with links to the images. Anything fancier (like replacing them with static images and links to actual videos rather than GIFs) can come later.
Please. I’m not trying to be mean in any way, but words are failing me at just how bad this is. You just don’t do this sort of thing. Entirely genuinely, you have probably directly cost at least a dozen people a few dollars with these GIFs, and measurably (sometimes seriously) inconvenienced dozens more for up to a month due to limits reached or approached.
It's a neat technology but still quite infant. I've heard that it currently takes longer to implement a non-trivial UI due to the compiler errors, documentation gaps, and bugs with the framework. Patience is required.
The latest stuff in beta since WWDC makes a world of difference. It’s a joy to play with, and I haven’t encountered any of the impenetrable compiler errors that the last version had.
I'm always very careful whenever apple release new technologies for devs. They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
> They promote it heavily but actually nobody uses it inside, and it's up to the community to go through all the bugs.
Large chunks of macOS 11 and iOS 14 are built with SwiftUI, and it's the only way you can build the newer style of widgets on both platforms. They're actually pretty aggressively dogfooding it.
They were slow to pick up Swift internally because they needed ABI stability, but no such barriers exist for internal adoption of SwiftUI.
I'm using it to port an auv3 plugin to a standalone app. The overall experience is amazing when compared to the constraint based method proposed in previous xcode versions. There are parts missing, but it's fairly easy to wrap uikit components and use them in swiftui
Meh. I am finding myself enjoying simpler calendars. It's a cute gimmick for like, playing with. But I prefer simpler for things I have to use all the time.
Simplest form: ffmpeg -i foo.gif -c:v libx264 -crf 22 foo.mp4
You can vary crf to change the size to quality trade-off.