Hi Brandon, thanks for the report. For reference, any links created on a particular account, including those returned by loadStreamableURLForFile, are subject to the bandwidth restrictions for links.
However, based on the numbers you've detailed, the usage here certainly wouldn't have exceed the limits.
Can you double check you're looking at the same account though? These link restrictions are per account, and it's easy to mix up which account is which when developing an app like this (e.g., work versus personal). Please check the account information for the account for the access token used to call loadStreamableURLForFile by calling loadAccountInfo. (You can also check the email address in the "to:" field of the email notification.) Then, compare that with wherever you're looking at to confirm there isn't other shared link activity on that account, e.g., the email address for the logged in account on the web site.
As far as alternatives are concerned though, while any links are subject to these restrictions, authenticated API calls are not, so a better solution would be to use loadFile, if possible. (I don't know if it would work well for your app in particular of course, nor do I have experience with AVPlayer.) In any case though, loadFile is a direct, authenticated API call (it uses /files (GET)) and is not subject to the bandwidth limits.
Finally, in case it would be useful for your app, /files (GET) supports Range Retrieval Requests, which would let you download arbitrary portions of a particular file, still not subject to the bandwidth restrictions. That's not implemented in the iOS Core SDK, but the SDK is open source, so you could modify it if/as necessary.
