The documentation lists the number of calls per month you can make for the different pricing tiers here: https://developer.apple.com/weatherkit/get-started/ but are there going to be any per second/minute/hour rate limits on calls to the API like with other weather service APIs.
For example maybe you get 1,000,000 calls per month but there is some limit like 5 calls per second or 10,000 calls per hour imposed by the APIs?
Also what happens if you go over your allowed call limit for the month, will the API just return an error like HTTP 402 or you will get a warning for a period of time? Would you be able to buy extra calls for the month without having to upgrade to a new tier, assuming maybe you are experiencing a temporary increase in traffic.
markdaws
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Hi - I don't see anything in the documentation about which regions of the world the API will support e.g. US, Europe. I see there is an /api/v1/availability you can call but is there some rough guidelines around what areas are supported and which aren't.
Thanks
Mark.
I'm not sure which combination of iOS/XCode/Mac OS is causing this issue, but all of a sudden when I try to run our SceneKit app and the "Scheme -> Diagnostics -> Metal -> API Validation" setting is turned off the scene won't render and the console is just full of the following errors:
Execution of the command buffer was aborted due to an error during execution. Invalid Resource (00000009:kIOGPUCommandBufferCallbackErrorInvalidResource)
[SceneKit] Error: Main command buffer execution failed with status 5, error: Error Domain=MTLCommandBufferErrorDomain Code=9 "Invalid Resource (00000009:kIOGPUCommandBufferCallbackErrorInvalidResource)"
)
If you run the app outside of xcode it's fine, also enabling the "API Validation" option stops the issue.
One of my schemes has this option disabled since the project began and never had an issue before. Just throwing this out there incase someone else has spent hours of their life trying to figure out why this is not working for them.
Also you can just create a new SceneKit project and turn that diagnostic option off and the app won't render anything.
Hi - I have an auto-renew subscription, for some reason when the user looks at their subscriptions in the iOS subscription list the subscription shows the productId as the name e.g. com.company.app.subscriptonName not the localized string e.g. "Foo Monthly Subscription".
I have other subscriptions and they all works as expected and show the localized name.
The one that is showing the productId is configured the same as the others as far as I can tell, any reason why this is happening and how to fix it?
Thanks.
Hi,
I am trying to test my subscription upgrade/downgrade path on a device. I added a test user to the sandbox section of Settings - App Store and can purchase subscriptions using that test user no problem in my app.
However, if I click on "Manage" on the sandbox user to see the list of subscriptions, when I try to upgrade/downgrade the purchase UI that iOS shows tries to use my actual personal account instead of the sandbox user, so I can't complete the transaction.
Looks like a bug in the sandbox testing flow in iOS, but any way around it? Right now I just simulate updates from apple on my backend to make sure my app behaves as expected, but I would like to actually get some "real" data from Apple.
I'm testing an auto renew subscription in the sandbox, one scenario I am testing is to make sure I can handle if I accidentally show the user the purchase button for a subscription they already purchased.
In the sandbox when the user clicks buy iOS pops up an alert saying the user already has the subscription, which is good, and doesn't charge again but then I receive one event for every subscription renewal the user has ever had, basically all their previous purchase history via:
func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction])
Is this expected behaviour in production, or just a sandbox quirk?
Thanks.
I added some logging to my widget and in console.app I can see that the widget getTimeline method is being called even when the users phone is locked. It's been over an hour with my phone locked and the widgets getTimeline method is still being called when the timeline expires.
I want the widget to refresh as little as possible when not visible because every call to our API costs money, I don't want widgets just sitting there hitting our server even if someone isn't looking at it.
Is there any way to disable this functionality and reduce the number of getTimeline calls when the widget is not visible or the phone is locked?
NOTE: I'm not running the app via xcode just incase that triggers some more frequent update path.
I added an intent definition to my widget, it has a type of "duration" and I set the minimum and maximum values to a range e.g. 1 -> 60.
When I edit my widget on the homescreen the intent is shown in the edit menu but I am able to enter numbers outside of the minimum and maximum values, I would expect the UI should prevent this.
Is there some extra code I need to add to get the UI to respect the minimum/maximum values I specified in the .intentdefinition file or is this a bug?
Running ios:beta7, xcode: beta6
Thanks.
When I run my widget from xcode I see getTimeline is called twice for some reason.
It's called the first time, then after it returns a timeline it's called again. The logs have the following message:
"-[EXSwiftUI_Subsystem beginUsing:withBundle:] unexpectedly called multiple times."
It takes about 0.5 seconds for the first getTimeline call to return so it doesn't seem like the OS should try to call this method again so quickly (my timeline entries all have times in the future so they shouldn't request the widget to load immediately)
Is this a bug, or expected? Seems to happen every time I run the widget.
In my app the user can change some settings, those changes affect how the widget looks. For example changing the colors, the units C / F, location etc.
When the user changes the settings I call WidgetCenter.reloadAllTimelines(), sometimes the widget will update immediately, maybe just once, sometimes it will after a minute or so and sometimes not for a long time.
This makes the whole experience feel broken. I understand apps shouldn't be allowed to abuse reloads of the timeline but it seems like at least the app can give a hint to the reload method e.g.
WidgetCenter.reloadAllTimelines(hint: .appearance)
Which when specified would give the widget update priority and maybe update immediately. Obviously there would need to be some allowances where you get two or three updates in a short time period then extended after that.
Right now it just feels broken to let users change settings in the app and the widget may or may not update in a reasonable time.
I have an IntentTimelineProvider in my widget. I added a single intent to allow the user to choose a location, I set the intent type to "Location".
This works, the edit widget option becomes available and the user can search for locations, however there doesn't seem to be any way to unset the location. If the user chooses a location then opens up the location dialog provided by widgetkit and selects "Done" without choosing a location then after that clicking on the location option in the widget edit menu does nothing.
The original "Choose" text is no longer shown and there is nothing to click on so the user can not set a new location without having to delete the widget and re-add it.
Looks like a bug, or is there some other way to provide a default value to the intent if the user doesn't choose anything.
Ideally there would be a "Current Location" option like in the weather widget options but I can't seem to find any option that would enable that.
Thanks.
I'm trying to develop a widget, I've been using a custom font. If I add the widget to the home screen maybe 70% of the time it will load, then randomly it will just start to fail and continually crash, just flashing white.
If I add multiple instances of the widget to my home screen then it will just crash 100% of the time. Both widget will just sit flashing and continually crash.
In the crash logs on my device I can see SwiftUI is crashing, on something relating to fonts:
0 SwiftUI 0x00000001e5c52f5c CodablePlatformFont.init+ 6733660
If I take the custom font out of the widget then it will load (eventually after resetting the device, widgets are sooo buggy) and I can have multiple instances.
I'm not sure if I am doing something wrong trying to use the custom font. I created a new project and included the same custom font and loaded it the same way (just adding it to the bundle and in the info.plist) and that does not seem to crash.
Just wondering if this is a known issue with custom fonts, if anyone has a workaround to stop it happening.
Here is a snippet of the crash stack:
Date/Time:					 2020-08-21 13:26:32.7104 -0700
Launch Time:				 2020-08-21 13:26:32.2918 -0700
OS Version:					iPhone OS 14.0 (18A5351d)
Release Type:				Beta
Baseband Version:		3.50.05
Report Version:			104
Exception Type:	EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001e5c52f5c
Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [8244]
Triggered by Thread:	0
Thread 0 name:	Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0	 SwiftUI											 0x00000001e5c52f5c CodablePlatformFont.init+ 6733660 (from:) + 2744
1	 SwiftUI											 0x00000001e5c52c54 CodablePlatformFont.init+ 6732884 (from:) + 1968
2	 SwiftUI											 0x00000001e5c52f88 protocol witness for Decodable.init+ 6733704 (from:) in conformance CodablePlatformFont + 20
3	 libswiftCore.dylib						 0x00000001b6feff80 dispatch thunk of Decodable.init+ 2957184 (from:) + 16
4	 libswiftFoundation.dylib			 0x00000001e3e1dd0c __PlistDecoder.unbox<A>+ 343308 (_:as:) + 372
5	 libswiftFoundation.dylib			 0x00000001e3e28860 _PlistKeyedDecodingContainer.decode<A>+ 387168 (_:forKey:) + 660
6	 libswiftFoundation.dylib			 0x00000001e3e2ac94 protocol witness for KeyedDecodingContainerProtocol.decode<A>+ 396436 (_:forKey:) in conformance _PlistKeyedDecodingContainer<A> + 48
7	 libswiftFoundation.dylib			 0x00000001e3e2a9f4 protocol witness for KeyedDecodingContainerProtocol.decode<A>+ 395764 (_:forKey:) in conformance _PlistKeyedDecodingContainer<A> + 20
8	 libswiftCore.dylib						 0x00000001b6d722cc _KeyedDecodingContainerBox.decode<A, B>+ 344780 (_:forKey:) + 296
9	 libswiftCore.dylib						 0x00000001b6d659e4 KeyedDecodingContainer.decode<A>+ 293348 (_:forKey:) + 40
10	SwiftUI											 0x00000001e5c4f5c8 CodableAttributes.init+ 6718920 (from:) + 832
11	SwiftUI											 0x00000001e5c503c4 protocol witness for Decodable.init+ 6722500 (from:) in conformance CodableAttributes + 20
12	libswiftCore.dylib						 0x00000001b6feff80 dispatch thunk of Decodable.init+ 2957184 (from:) + 16
13	libswiftFoundation.dylib			 0x00000001e3e1dd0c __PlistDecoder.unbox<A>+ 343308 (_:as:) + 372
14	libswiftFoundation.dylib			 0x00000001e3e2b32c _PlistUnkeyedDecodingContainer.decode<A>+ 398124 (_:) + 776
15	libswiftFoundation.dylib			 0x00000001e3e2d150 protocol witness for UnkeyedDecodingContainer.decode<A>+ 405840 (_:) in conformance _PlistUnkeyedDecodingContainer + 12
16	libswiftCore.dylib						 0x00000001b6d7cbd0 Array<A>.init+ 388048 (from:) + 332
17	libswiftCore.dylib						 0x00000001b6d7d178 protocol witness for Decodable.init+ 389496 (from:) in conformance <A> [A] + 28
18	libswiftCore.dylib						 0x00000001b6d7cc8c protocol witness for Decodable.init+ 388236 (from:) in conformance <A> [A] + 20
19	libswiftCore.dylib						 0x00000001b6feff80 dispatch thunk of Decodable.init+ 2957184 (from:) + 16
20	libswiftFoundation.dylib			 0x00000001e3e1dd0c __PlistDecoder.unbox<A>+ 343308 (_:as:) + 372
21	libswiftFoundation.dylib			 0x00000001e3e28860 _PlistKeyedDecodingContainer.decode<A>+ 387168 (_:forKey:) + 660
NOTE: I am using the beta5 build
Is there a way to cause getTimeline to be called every time you run the widget in xcode?
Right now when the widget is first installed (via building and running via xcode) getTimeline is called as expected and I can set a breakpoint in xcode. However, after that recompiling and running the widget will not cause getTimeline to be called until the timeline has expired.
This means I have to delete the widget every time I compile and make a change to be able to debug.
I updated to the beta3 version of xcode + iOS. After updating after running my widget it sometimes displays but most of the time it is just white, then all the other widgets just sit there flashing white including the Apple widgets such as Weather, Stocks etc.
Anybody else seeing this or know a workaround? I tried deleting the widget and the app and re-installing but nothing seems to fix it.