What's the best way to test against all the various exceptions one can get while going through the account kit phone number verification work flow? I'm seeing complaints from my users - some of which are tough to replicate. And since it's a live app, the error messages aren't highly descriptive either.
Related
With Apple getting ever more stringent by enforcing 2FA on all iOS accounts, a unique challenge that we've encountered is how to setup a system where Apple’s 2FA codes for a shared dev account can be forwarded to perhaps our private slack channel? Hence enabling multiple members on a team access to Apple’s services.
I got so annoyed by this that we then developed a hack.
It’s a Python script that’s running in a terminal on the mac mini CI machine and using some vision SDK tooling, checks the screen every few seconds for the 2FA dialog pop-up.
If it finds it, it then navigates the pop-up, crops the 2FA code, does OCR on it, and relays the code through the Slack API to a dedicated internal buildbot channel that our devs get notified on.
Sample cropped 2FA code screenshot:
The result, is the general shared apple id account is now much more convenient and efficient to access by our devs for CI/CD or any other client App Store info updates.
So that’s one way to do it. 😎
I've noticed in the AWS console that our website got a lot of more requests than normally. Especially in the night hours (Europe time).
Then I've checked the nginx logs and now I know that a lot of devices with different IP addresses request the root of the website, most of them with the user agent swcd (unknown version) CFNetwork/978.0.7 Darwin/18.7.0. Sometimes one of the versions is different.
I have absolutely no idea what is going on so I hope that someone can help.
swcd runs on iOS and macOS devices and will periodically attempt to access /apple-app-site-association and /.well-known/apple-app-site-association. This is used for several features which mediate between an Apple native app and the web, including Shared Web Credentials, Handoff, and Universal Links.
This process will typically run overnight in the user's local time zone, but specific timing is not guaranteed.
See also Setting Up an App’s Associated Domains for more information on associated domains.
Hard to guess the cause of the spike without knowing more about your product - but some possible causes:
you recently released an update to your iOS or macOS app
a larger customer just signed up for your service or rolled out your product to more employees
a larger customer just deployed an iOS or macOS operating system update to their managed devices
Anyway, I would ignore the spike. If it's causing you trouble, ensure your load balancer is configured correctly.
Recently this same behavior was detected by our CDN and our WAF's, and what we detected here in some clients, was a botnet doing enumeration of users in a distributed way, there is even a name for it, user enumeration spraying.
Anyone who doesn't know how web attacks work would say this is normal.
Looks to me like someone with a botnet is trying to take advantage of the shared web credentials to compromise your site, doing it at night to try to avoid detection. Other evidence is the "a lot of devices with different IP addresses request the root of the website". If it was just a "viral" event, just certain classes of devices would show, rather than a wide diversity of devices. Accessing the root of the web-site -- these are devices that have never been to your site before. It's not a denial of service attack because they are doing it at night, therefore not denying anybody their service, and night is the natural time for break-ins.
I'm not a cracker myself, just an old-school developer, and I'm not even terribly familiar with ios, but I could not remain silent while there was a possibility that your web site was attacked without you at least suspecting and investigating. HTH.
There are two new StoreKit errors that have come up in iOS 9.3. I'm trying to make sure my app handles errors in the best way that it can, so was hoping someone could explain what they mean in terms of when they would be called, how you might handle them, and in what cases they wouldn't be called where they normally would?
According to Apple's documentation:
SKErrorCloudServicePermissionDenied
: Indicates that the user has not allowed access to Cloud service information.
SKErrorCloudServiceNetworkConnectionFailed
: Indicates that the device could not connect to the ne(t)work.
First of all, what is Cloud service? And what does it have to do with StoreKit? When I think of Cloud Service, I think of CloudKit and iCloud. But these technologies, to my knowledge, aren't used in StoreKit. Or if they are, no one told me, and WWDC hasn't explained it either.
How could one turn on/off cloud service, and if it's just iCloud, then would that actually stop an IAP from being processed? I don't think so.
And for the SKErrorCloudServiceNetworkConnectionFailed, by the description, that sort of sounds like something that would've been implemented long before iOS 9.3 (checking handling an error such as not being able to connect to the network). Of course, if it's not just 'the network', but rather this unknown CloudService network they're talking about, then maybe that's something different?
Hello all I am developing a extension app which will fetch-
The people you contact the most.
Most frequently used apps.
Any body have idea, How can I get these things.
Thanks in advance.
This is not possible. Your app runs in a sandbox, which means that it is very limited in how it can interact with the rest of the operating system. This is to prevent security vulnerabilities from apps snooping on a user's behavior. For more information on this, and to see what you can and can't do in the sandbox, see https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html.
While you are developing your application, iAd Network sends test
advertisements to your application. To assist you in validating your
implementation, the iAd Network occasionally returns errors to test
your error handling code. You can also test your error handling
support manually by turning your device’s wireless capability off.
Ok, it says the above in the developers guide, but in reality its failing more often than serving the test page, for 2 days now! I get a the test ad page once every 10 minutes it seems !!! Little disproportionate for testing.....
Is this how it's going to be in live? I don't want to be deploying my paid ap for free if it's not even going to send any ads!
Anyone got any experience of this?
By experience it is very variable in test environment, I've seen days as you describe and days with a good flow of ads. Now ... live it is very different, the "fill rate" as they call it (% of requests answered with and ad) is pretty low, maybe 2% on iPad and 5-10% on iPhone. Besides, iAd serves ads only in certain countries, ie. mostly in US and a bit in the UK, France, Italy, Spain, ... And by experience it serves more ads to the iPhone than iPad. My app on iPad received virtually nothing outside the US from iAd.
Now on the positive side, the remuneration of ads is the best for iAd when you have the chance to receive ads. I ended up implementing a fallback network (AdMob) when iad doesn't receive anything. I did that myself but read there is something called AdWhirl that seems to provide help on that.