Yes, yes, the point was that you cannot compare providing a free software with running the App Store. It requires more sophistication, once security issues, sensitive personal information and a large number of different services, parties are involved.
Your point is misguided. First as I outlined should decouple downloading from this more secure infrastructure you seemed to be fixated on. Second, if you do have secure infrastructure you want to keep that as
small as possible.
To do millions of transactions per day shouldn't, at its core, take more than 3-4 servers. 6-8 if running a DR backup in mirror mode. To illustrate.
http://tpc.org/tpcc/results/tpcc_price_perf_results.asp
Notably the last one, the 639,253 tpmC, at the bottom. That one server, Oracle Standard Edition DB, is doing 600K transactions per minute. Not day; per minute. The super "high" rate App store is doing 6.3 million per
day. Scaled up to a day rate that one server is doing 864 million transactions per day. Sure, the store transactions aren't going to be the same as the tpc benchmark transactions, but even if 10 times more complicated/slower still 10 times more than the throughput rate. (**) So back of the envelope, where is the huge infrastructure here????? Somewhat expensive (compared to common stuff in the Apple Store. Will probably need enterprise edition, partitioning , RAC , and data guard Oracle DB software) ... yes, but huge (in terms of servers required) ... no
Since a decent modern DB server with decent software can do 100K's of transactions per minute, where is this huge infrastructure you are talking about? Sure there are larger number of store fan-in app servers, but there are clones of each other and store no sensitive data (just like the download farm). More than likely, there is one Oracle RAC cluster that has the secure stuff and another running in Data Guard mode as a backup.
For the sake of modeling the operation, 20 full-time employees dedicated to the App Store would cost millions of dollars.
We've now gone from 'largest IT operations' down to about 20 folks. I'll spot you double that: 40 folks. That's not even in the ballpark of the 'largest IT operations".
If we seriously take the whole extra ectivity into account - including PR, marketing, legal tasks, network infrastructure, Apple developers, mid-managers, accounting; overall, 20 'full timer' seem unrealistically few.
So take another 1/2 cent out of each download. Up to a whole penny now ($0.01) and pay for these folks. Once get into the "billions served" can take very small amounts and add modest amounts expensive overhead with little problem. However, 700 Million versus 2 billion downloads themselves isn't where the huge increase in costs to scale are.
Add the cost of increased infrastructure to that, and suddenly you get several-several millions of dollars as 'overheads'. If that tens of millions as revenue is true, the whole App Store is still not that great.
Your comments suggest a mental model that puts the secure data onto 100's servers. That is a fundamentally flawed design. For what Apple is doing a 1/2 dozen is plenty. Similarly large numbers of "worker" clones don't really require low ratios of servers to admins. When they are similar, limited function clones can have higher than average server/admin ratios.
(**) The tpc benchmark as a limited write rate (more reads than writes.). However, for the store there pragmatically is not limitation on inventory. You produces copies of the software upon request. So there is no need to see if the software is in stock or not. If deployed to the download servers it is there. So all tracking is a log of what got bought/downloaded. ( in contrast to amazon where selling a physical book and have to reduce the number in inventory by 1. ) So with independent writes can't see what is blocking much here. The bottleneck of writing to the DB log is probably a more major limitation here.
