Latest Contributions by Nicholas-Furness

Hi @SalvadorApltp . The License string and the API Key are different things and independent of each other: The License string removes the developer watermark and enables specific capabilities of the SDK (depending on the license level). You always need a License string to deploy your app to production. If you don't provide a License string, you can use all the capabilities, but only for development and testing. The API Key grants an access token you can use to access hosted content. You only need an API Key if you are accessing private content (as you are). See these topics for more information (note, I am linking to the ArcGIS Maps SDK for Kotlin documentation since the ArcGIS Runtime SDK for Android is in extended support): Licensing levels and capabilities (expand the "License strings vs API keys" note). Security and authentication In this reply I focused on API Key because that seems to be what you're using, but note that API Key is just one way to access secure (private) content. You can learn more at the Security and authentication link above. ... View more

Hi @MaríaBencomo  Glad that improves things, but I'm curious why you're using densify at all. For straight-line segments you shouldn't need to. I could be missing a nuance of your use case though. ... View more

I assume the route is being drawn using your own custom code and stored as a Graphic (the pathRoute above looks like a GeoElement of some sort - can you confirm if it's a Graphic or a Feature, though it shouldn't make a difference). It looks like sometime between tapping the 4 points and writing it out to JSON, it is being densified somehow. Do you have any code that calls GeometryEngine.densify() or .densifyGeodetic()? ... View more

Just posted an update on the Xcode 16 issue. ... View more

Hi @MikeLeavy. As experienced iOS developers, the team is as excited to work with iOS 18 as everyone else, and we have been working closely with Apple to identify a solution since Xcode 16 RC was posted last week. It did surprise us that Xcode 16 RC did not address this Swift Concurrency compatibility issue since we had raised it with Apple early in the Xcode 16 beta and, historically, compatibility issues like this have often existed through the entire Xcode beta period only to be resolved in the RC.  In our discussions with Apple last week, they did not completely discount the option that the Xcode bug could be fixed in final, but we expect it will not. With that in mind, we will be publishing guidance today, and rest assured we're working hard to come up with a solution, which we hope to deliver this week. In the meantime, if you want to use ArcGIS Maps SDK for Swift 200.5, you will need to do so with Xcode 15. ArcGIS Maps SDK for Swift 200.4 should work with Xcode 16, but I only mention that in case it helps to tide you over. We recognize that for most, these options are not a good solution, and the current situation is highly frustrating. I'll reply to this thread as soon as we have a solution. ... View more

I'd just add to @KoushikHajra's reply that visual analysis was deliberately designed and built to work only on what you see on the display. That's part of the reason that the actionable output of the analysis is very limited (e.g. we don't provide a polygon output from the viewshed analysis). What Koushik alludes to is that to deliver a performant and responsive display, there's a lot of trade-off that has to happen on different devices in consideration of their GPU, CPU, memory limitations, and data loads. As he mentions, desktop systems can afford to less aggressively reduce LOD levels at distance, but at 50km you'd almost certainly still see degradation. Rather, the way to get an accurate and actionable analysis is to use the Geoprocessing APIs to make a request to a GP service. See the API Reference, and this viewshed sample. All that said, we are always interested in identifying ways we can improve the SDKs so if you could DM me with more details on your use case, I'd like to learn more about what you're trying to build here. ... View more

Hello @CristhianSanchez. Please could you DM me with some more details? We'd like to reproduce this and see if we can work out a solution. We'll need some data and a self-contained reproducer project. Thank you! ... View more

Hello. Thanks for the question. At the moment there is a known limitation in ArcGIS Online that prevents the Preplanned Offline Map workflow working with API Keys. Credentials will work, as you've noticed. However, what you're encountering is that the way the SDK is architected, if you set a global API Key on the ArcGISRuntimeEnvironment, then that will be used without even considering any credential you might set. One thing you could try to do is to clear the global API Key before running your code above and then setting it again once the callbacks have completed. That will clear the way for the OfflineMapTask to use the credential you provide. I do want to clarify one thing though. You say "Same thing happens if I have not set the credential above and set the apiKey." Can you confirm that you mean that if you do not set the credential, but do set the apiKey, then the preplannedMapAreas come out as empty? (this is what I would expect) I would like to know if there is a way to set the apiKey locally in a function, instead of globally, so that I can still load the arcgis map with the apiKey Unfortunately not in this case. Typically, anything that implements ApiKeyResource can be provided an explicit API Key to use in preference to any other authentication method (including a global API Key). However, in the case of a Map opening a web map, there are some nuanced reasons that meant we could not expose that functionality in this case, and so the only way to use an API Key to access a web map is to use the global API Key. It's something we plan to review and see if we can improve, but currently that's a known limitation with API Keys and web maps. Alternatively, is there a way of loading an arcgis map without the api key, but using the credentials instead? Absolutely, however if there's a global API Key set, as I mentioned above, that will override any credential in this case. Does this help? ... View more

FYI, there is also this post from a while back which might be of interest. It doesn't quite tackle your specific use case and focuses on Mobile Map Packages from Pro, but it does talk a bit about what's going on within them which could be helpful. ... View more

To open local raster files in the SDK, you'll generally need a couple of support files. A world file to describe the image-to-world transformation, and an aux file to specify a spatial reference, so that the SDK knows how to handle that georeferenced image file. See this gist for an example. The links at the bottom talk about the world and aux files, as well as what to name them. I've found that just using the aux file from the gist wholesale (with an appropriate name) and writing out an appropriate world file based off the instructions in the links, and placing them alongside the image file on device storage works well. This will require a Standard license or above, but if you're using Local Server, you're already there (and of course while you're developing, without applying any license, you can also test this out). You should also be able to use Local Server for serving up rasters, but if you can get the aux and world files working that might be a simpler approach. ... View more

Hello Frank. Thanks for reaching out. Firstly, you will benefit tremendously by using the ArcGIS Maps SDK for Swift over direct REST requests (unless you're just making very simple calls to the ArcGIS Location Platform places or geocoding service). We have numerous tutorials at the SDK's homepage: https://developers.arcgis.com/swift/ I suggest you start with this one, which will introduce you to some concepts around API Keys and the SDK in general: https://developers.arcgis.com/swift/maps-2d/tutorials/display-a-map/ But I also suggest you go through the getting started pages at the SDK homepage. You can also see these blog posts that we wrote around getting started with the SDK, although they will probably be slightly out of date as we just made some major changes to how API Keys are created and managed: https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-1-maps-and-app-structure/ba-p/1289024 https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-2-state-and-data-f... https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-3-swift-concurrenc... https://community.esri.com/t5/arcgis-maps-sdks-native-blog/let-s-build-with-swift-4-view-modifier-an... The new ArcGIS Maps SDK for Swift is the modern continuation of the old ArcGIS Runtime SDK for iOS. Learn more here where we first announced the modernization of our SDKs back in April 2022, and here, where we cover the initial release of the new SDKs later that year. With that in mind, we do indeed discourage use of the old Objective-C ArcGIS Runtime SDK for iOS (which provided UIKit UX components), and although it is a long-term support release, it will eventually cease to receive support. Apple's stated path forward is Swift and Swift UI, and this is what we've committed to with the ArcGIS Maps SDK for Swift. However, Apple provide an easy way to use the Swift UI components with UIKit using a UIHostingController (see Apple's doc here and here), and we have customers who are successfully doing this. As for authentication, you can learn all about using our API Keys and OAuth here: https://developers.arcgis.com/swift/security-and-authentication/ Which one you will use will depend on the type of app you're building and who will be using it. As a general guide, many Esri end users are direct users of the ArcGIS system and have their own logins which enable access to content and services. These customers may well need to use OAuth authentication. But if you are building apps that are to be used by end-users without an ArcGIS login, an API Key is more appropriate. I recommend you create yourself a free ArcGIS Location Platform account which will allow you to create and use API Keys of your own. There are generous free monthly allowances allowing for development and testing, and which can also be used in production. If your customer has given you an API Key, you can certainly use that and it ensures that any usage beyond the free allowance will be billed to them (or just fail if they haven't set up payment methods), but there are a couple of disadvantages to that that I can think of. Firstly, API Keys are scoped, and if you need to provide access to additional services, the customer who hired you will become a bottleneck. Secondly, you won't have insight into usage levels for the API Keys, nor the ability to create additional ones. However, if the API Key is just going to be used for simple stuff like accessing basemaps and performing geocodes or place searches, you might be able to get away with it. More likely though, using your own account during development and testing will work well, and then the customer can provide an API Key for production. I hope that helps. ... View more

Hello. Before I answer your question, I want to make sure we're talking about the right thing… Firstly, named user vs license strings: As you mention, license strings for paid license levels (Basic, Standard, and Advanced) are purchased in packs. But the Lite level license string is free and can be used as much as you like. If the capabilities of your app are all included in the Lite license, that one Lite license string is all you'll need. See here for which capabilities are available at each level. And see here to get your Lite license string. Next, you say "The Named User license with standard privileges, such as VTPK load, seems like a suitable option.". I want to make sure we're talking the same thing here. "Standard" is a license level that, in brief, allows you to open non-Esri-proprietary local data files, like GeoPackages, Shapefiles, ENC, local rasters, etc. (see this link again for full details of what you get at Standard). However, a VTPK is an Esri-proprietary file (like MMPKs, TPKs, TPKXs, etc.) and so can be opened locally at the Lite level. If that's what you need, Standard might be overkill and Lite might suffice. Now, to the question of renewing licenses. License strings can be used in perpetuity. There is no need to "refresh" the license (they are designed to encompass scenarios where a network may never be available). This is true for the free Lite license string, as well as the string(s) you get when you purchase any Basic, Standard, or Advanced deployment pack(s). Named User licenses can be taken offline for 30 days, as you noted. The pattern is this (as described here) : While online, your user signs in. Your code then requests the license from the portal they signed in to. You apply the license in your app, and optionally serialize it to local storage for later use. Whenever your app is subsequently started (probably while offline), you can de-serialize that license and apply it. No network is required. Of course, if you have a network, your user could sign in again (returning to steps 1 and 2). How does the SDK ensure the license reaches its expiry? The encoded license data downloaded in step 2 includes the expiry date, and the SDK compares that to the current date. Whenever you repeat steps 1 and 2, that new license data will effectively have a new 30 day countdown start date encoded in it. I hope that helps. ... View more