Post

Replies

Boosts

Views

Activity

Publish a single app with different server addresses and different flows for each country
Hi everyone, I'm wondering which approach could be the best to publish an app that has a different server address for each country and sometimes even the flow changes (eg. some checkout steps are present in some countries and not in others), sometimes even some third party libraries used may be different between countries. At first I thought about making a different target for each group of countries that shares the same features, so I would not bloat the bundle with unused dependendencies and code files, but since there's much more in common than what's different, then I would most of the time have to go through many app reviews for a single change and that would not scale. If I publish instead a single binary for all of the countries my app supports, what's the right way to detect the user's country? Because the region I get in Locale.current can be manually changed from the user in the Settings and may be different from the App Store region so I'm wondering what could I do if I get a region my app doesn't support. Another problem I see with the single binary approach is how could my testers test each country's version if I don't use the Locale.current region? My app is well localized so it would already support the single binary approach as is. Thank you very much!
0
0
414
Jun ’20
How to cache the result of a Publisher that performs a network request
Hi everyone, While transforming a task that performs a network request into a Combine Publisher, I came across the .share() and .multicast(_:) operators that offer the possibility to share the same stream, in this case a network request, across multiple subscribers thus avoiding new subscriptions to trigger a new network request while there's already one in progress. These, anyway, only work while the request is in progress, after the request is finished any new subscription triggers a new request. Does any of you know of a way to make this cacheable so that any new subscription after the first network request finished just gets the result without triggering a new request? Maybe with a cache expiration time, too? I think this could be a nice way for implementing getting and renewing an authentication token, for example. Here's some sample code of how these operators can be used. let pipelineFork = PassthroughSubject<Data, Error>() let expensivePublisher = somepublisher 		.share() 		.multicast(subject: pipelineFork) Thank you very much and have a great WWDC!
0
0
721
Jun ’20