App Store web has exposed all its source code
reddit.com280 points by redbell 7 days ago
280 points by redbell 7 days ago
sourcemaps should be enabled -- that's how people learn.
a lot of people learned to code on the web via viewsource - now we are obfuscating the code
Probably due to usage of fat front end frameworks which also include whole business logics.
sourcemaps are not for learning, it's for debugging
Some sites want to ship small bundles to the client by default, sourcemaps enables that + you get to introspect it because it's downloaded only when requested. Literally best of both worlds :)
I love shipping source maps for my stuff bc it lets other developers take a peek and I love doing that with other peoples sites :)
Idk why you are getting downvoted.
To elaborate on your comment, if you just ship sourcemaps in production, that means you can ship minified code and track down what _actual_ source that you _aren't_ shipping to users is getting called, is in stack traces, etc.
I'm not aware of a point of sourcemaps otherwise.
Yep, sourcemaps are essential to get usable error stack traces, and that's their only purpose.
You mean it's no longer built with WebObjects!
Java has it's place but it was delivered in such a way that it created an immense amount of collateral damage and lasting technical debt.
WebObjects was originally written in Objective-C.
Now that's a fine language for a server. It combines the type safety of Ruby, the memory safety of C, and the terseness of Java.
(I'm joking, mostly... Actually I was a big fan of Obj-C for desktop apps. Fond memories of times when I didn't have to care about servers and ever-changing web frameworks.)
I was kinda trying being funny or sarcastic or something like that :-)
And amusing to myself how many people actually remember or know what WebObjects was!
All I know about is it the great box art. It always looked so cool and mysterious to me as a young developer.
The same with everything called "XSan" and "Mac OS X Server". I don't know what any of it was, but the box art was always so cool.
OP here..
Here's the original post by the author of the repo himself: https://old.reddit.com/r/webdev/comments/1onnzlj/app_store_w...
The github link in the reddit post is taken by DMCA
Yes, but the full source code was archived here: https://archive.softwareheritage.org/browse/origin/directory...
As a frequent user of the backend (Connect), I am skeptical that this is source that you want to reproduce (unless you're a scammer).
The source code had a very elegant and systematic use of intents (including prefetched intents) and a dependency injection container.
The pattern itself is a little bit different, has some conceptual overhead, but it's also fairly clean and scaleable.
Yeah, it was a bit of a joke.
I’ve been staring at Apple source code (the stuff they let The Great Unwashed see), for almost forty years.
It’s always been very polished, well-structured, well-documented, succinct, and beautifully written.
It’s been an inspiration for my own work. I have always striven to emulate them.
That’s why it’s so shocking for me to encounter the terrible quality of the Connect backend. It’s quite painful, and disappointing.
I remain convinced App Store Connect is the project they put interns on. It also explains why they keep redesigning / reimplementing it, then losing interest and leaving it part-finished and incoherent. It’s because the interns working on it go back to school.
Is there any reason sourcemaps are a genuine problem? I'm out of touch with the JS world, but I wonder if code is shared between server and client and server code may show in sourcemaps.
If obfuscating code is a necessity then sourcemaps are a necessity as well, they should just not be available in production.
That's if your goal is to obfuscate code.
Often though, Javascript is hard to read not because it's been obfuscated, but because its been transpiled and/or minified for smaller network payloads.
I can understand why some don't want to ship their sourcemaps to prod, but also it really doesn't matter all that much.
If your goal isn't to obfuscate code as you said you still need to do some kind of transformation so sourcemaps are necessary. It's possible to debug code that's been converted from ES2025 to ES3 without them but it's really annoying to have to do that.
Let's be honest, when a company makes a website they want you to see the website not the code. Of course front-end code is less private in nature but still, showing it could expose some vulnerabilities.
I remember when all websites “exposed” their source code.
And some webmasters were pretty keen on interfering with the context menu and your shortcut keys in order to prevent you to see it (and failing).
Told ya: https://news.ycombinator.com/item?id=30337690
This issue is very wide-spread.
> It exposes all your frontend source code for everyone. If you don't want to open source your frontend, you might want to remove those source maps from public access.
I wonder how much difference LLMs today have on being able to turn minified JS into something easily readable? JSNice already worked pretty well and I guess that was comparatively naive. You won't really stop anyone motivated to reverse-engineer it by not providing source maps, but you'll definitely stop at least some curious people from understanding how websites work. Your frontend also doesn't suddenly turn "open source" just because you shared the original source via source maps, that part sounds kind of FUD.
Oof! You certainly did, I remember reading this and not thinking that much of it at the time.
Still not sure What was the excitement about.
Was it, HTML, CSS & Javascript?
It's written in Svelte, which personally I'm excited about just because it means that a pretty big tech company is using it :)
And the "leak" is fun for me because you can see how they write their components haha
Apple Music web is written in Svelte as well. At least last time I checked.
Can you tell me what is the number 1 feature that Svelte has over the incumbents like React?
Not so much features as design.
Svelte files look like HTML+TS files. You aren’t learning some abstraction to HTML, you are just using HTML. But it adds the modern bits you need: reactivity, loops, components, routing, etc. Nothing react doesn’t have, but the devex is great.
Other benefits:
- your app is compiled. You don’t ship the framework to clients, they just get a minimal compiled app.
- The rendering modes are pretty great. Any page can be server side rendered, or client side, with per page flags. You also can easily setup SSR for the first page, and CSR for later pages - both the fastest option. It will even pre-fetch the next page when you hover a link, making most nav instant.
Radically simpler reactivity that doesn't require 20 different hooks to do the same thing.
Same goes for most modern frameworks (Solid, Vue, Preact) and even old ones experiencing a renaissance like Angular.
(Not a user, just evaluated it previously. Please correct what I got wrong.) They compile the reactivity statically, so instead of tracking effects at runtime, they generate code for it. I'd guess it means slightly more JS to download, but less initialization in runtime.
However, they recently added runtime reactivity to be more flexible, so it seems to me they are becoming VueJS.
I wonder what the heck @jet is. Never heard of that before. Must be an internal lib?
In case you want to save sources with the ability to fetch all possible lazy chunks, last year I made a tool to do exactly that: https://github.com/zb3/getfrontend
(note it won't work on apps.apple.com because apple has removed these sourcemaps)
How DMCA can take down code that was published in the web?
Copyrighted content is copyrighted content. It doesn’t matter if/how Apple published it, others don’t have a right to redistribute it without a license.
There was Cappucino by ex-Apple employees, and actual Apple devs had SproutCore. So where did they go? Why some unknown libraries?
It's using Svelte, I wouldn't exactly call that unknown. Why maintain your own library when a third party one does exactly what you need?
Unsurprisingly there are many frameworks/initiatives that end up falling by the wayside over the years, e.g. MacRuby was being lined up to supersede Objective-C for app development at one point.
Didn’t SproutCore become Ember [1]? Just my vague recollection, not sure if that was the case though. Anyway, Ember is still used and maintained, despite not being very well known.
App store uses svelte? :o
And the Windows 11 start menu is just React Native. Strange times indeed.
It's pretty clear to me that JavaScript is becoming the de facto standard for UI/UX programming, regardless of platform, and regardless of web vs. native targets. Even GNOME has JavaScript bindings. [0]
[0]: https://gjs.guide/
Personally I love it. HTML/CSS is still the best, most well documented and familiar gui framework
The problem is performance... requiring a web browser to draw a UI takes a LOT of CPU and memory, and not all devices have enough power to deliver a smooth experience across all potential workloads.
I worry that every year we keep increasing our processing requirements and bloat without good reason for it.
Why should every Windows release require a faster and faster CPU, and more and more RAM?
The recommended amount of memory for Windows 95 was 8 megabytes, and for Windows 11 it is 8 gigabytes. Why is this not horrifying?
My small Linux system with openbox GUI barely cracks 100MB memory usage in 2025.
> requiring a web browser to draw a UI takes a LOT of CPU and memory
What makes a browser so much more inefficient vs. other UI frameworks? Is it really the browser's fault or the website's you're visiting?
What makes the browser slow and inefficient is the fact that it's not a UI framework. It's a system to display text and a couple of images on a 2D plane where every element depends on every other element.
Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it. It's basically Microsoft Word, with nearly the same behaviors.
And there are no proper ways to prevent that behaviour. No lower and low level control over rendering. Awkward workarounds and hacks that browsers employ to try and minimize re-layouting and redrawing. Great rejoicing when introducing yet more hacks for basic things: https://developer.chrome.com/docs/css-ui/animate-to-height-a... etc.
> It's a system to display text and a couple of images on a 2D plane
And how is that different from a UI framework?
> Almost every single interaction and change requires the browser to recalculate the layout of the entire page and to redraw it.
What UI frameworks don't do this?
> And how is that different from a UI framework?
In none of them text is primary and all other incidental?
> What UI frameworks don't do this?
In which UI framework actions like "set focus on an element" triggers a full page re-layout?
Also, in which UI framework there's even a discussion of "try to not trigger re-paint/re-flow"?
And yes, I know about immediate mode UI where the entire layout is re-calculated every frame. But then they can usually render thousands of elements at 60fps.