{"id":59146,"date":"2025-12-15T10:05:00","date_gmt":"2025-12-15T18:05:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=59146"},"modified":"2026-01-08T16:09:24","modified_gmt":"2026-01-09T00:09:24","slug":"how-to-build-ios-widgets-with-dotnet-maui","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/how-to-build-ios-widgets-with-dotnet-maui\/","title":{"rendered":"How to Build iOS Widgets with .NET MAUI"},"content":{"rendered":"
\n

This is a guest blog from Toine de Boer<\/a>.<\/p>\n<\/blockquote>\n

I’m a .NET developer primarily focused on .NET MAUI to ASP.NET backend services. Because I recently have worked a lot with Widgets and encountered many obstacles and very limited documentation in the initial phase, I decided to write this article to show that it is absolutely possible to build complete Widgets with .NET MAUI. And to do so in a professional way comparable to using the native development environment, without having to fear that everything might break with every new build or update.<\/p>\n

This isn’t a hands-on tutorial; instead, these are the biggest and most important parts in order of how to tackle the biggest obstacles when building an iOS widget. It’s advisable to have some experience with .NET MAUI or Xamarin, and access to macOS is required, as creating an iOS Widget without macOS unfortunately isn’t possible. You can cherry\u2011pick what you think you need, but I recommend reading from start to finish or you may miss small details that keep the Widget from working. The text starts with creating a simple static widget, and ends with a basic system for a fully interactive widget.<\/p>\n

To help you get started quickly, I have created a fully functional interactive widget, which is available on\ngithub > Maui.WidgetExample<\/a><\/p>\n

\"Screenshot<\/p>\n

<\/i>Note<\/strong><\/p>iOS Widgets are standalone apps that are linked to a host app. For simplicity I mostly refer to the .NET MAUI app as the ‘app’ and the Widget app as the ‘Widget’.<\/div><\/p>\n

Prerequisites<\/h2>\n

Before we begin we need a few things from Apple’s developer console. Besides the Bundle ID of your existing app you also need a Bundle ID for your Widget. If your app uses com.enbyin.WidgetExample<\/code> then conventionally you append something for a Widget such as com.enbyin.WidgetExample.WidgetExtension<\/code>. Additionally, both Bundle IDs need the App Groups capability with a dedicated group. Create a Group ID by prefixing the app Bundle ID with group<\/code>, for example group.enbyin.WidgetExample<\/code>.<\/p>\n

What to collect from Apple Developer Console:<\/p>\n

    \n
  • App Bundle ID (e.g. com.enbyin.WidgetExample<\/code>)<\/li>\n
  • Widget (App) Bundle ID (e.g. com.enbyin.WidgetExample.WidgetExtension<\/code>)<\/li>\n
  • Group ID (e.g. group.enbyin.WidgetExample<\/code>)<\/li>\n<\/ul>\n

    For demo purposes I created a default .NET MAUI app targeting only iOS and Android. I set the iOS target to the newly created Bundle ID com.enbyin.WidgetExample<\/code>. I also added a very noticeable app icon so we can easily observe if the correct icon has been used on the Widget screens.<\/p>\n

    Creating the Widget project<\/h2>\n

    Let’s begin with the biggest step for me as a .NET developer: working on Xcode and Swift. After creating the projects in Xcode, I can recommend to switch to VS Code and pair with Copilot to iterate quickly. You can have a solid small app set up quickly while following Apple’s conventions.<\/p>\n

    I begin in Xcode by creating an app project using the App template using Swift coding. This serves as the base project to which I attach the actual Widget extension, and optionally, I can use it for some light testing. I give it the same Bundle ID as the .NET MAUI app has; reusing a Bundle ID is not a problem because this almost empty Xcode app will never ship.<\/p>\n

    \"Creating<\/p>\n

    With the app project in place, create the Widget extension next. In Xcode go to File > New > Target and choose the Widget Extension<\/code> template. Pick a name that already uses the correct Bundle ID for the widget so you avoid later edits. To simplify generating sample data select the Include Configuration App Intent<\/code> option; this gives a working widget immediately.<\/p>\n

    \"Creating<\/p>\n

    When all projects are created I always align the desired iOS version, make sure it is the same for all Xcode targets. To check this just tap the solution name to open the solution settings in the main window, then set for all targets on tab ‘General’ under ‘Minimum Deployments iOS version’. Now give it a trial run on a device using Product > Build in Xcode.<\/p>\n

    Objects and flows inside the Widget<\/h3>\n

    Creating the Widget project in XCode generates many objects. Understandably it is overwhelming at first, especially because almost everything is placed into one file. Therefore I always start by refactoring: moving every object into its own file and add some folder structure. You can do this without penalty because Swift does not really use namespaces; everything inside this project effectively falls under the same namespace regardless of folder structure.<\/p>\n

    After refactoring the flow is actually straightforward. Here are the main objects, functions and their roles:<\/p>\n

      \n
    • WidgetBundle<\/strong>: the entry point of the Widget extension, here you can expose one or more widgets to the end user<\/li>\n
    • Widget<\/strong>: the configuration of a specific widget, here everything is listed such as the View, Provider, ConfigurationIntent and the supported sizes<\/li>\n
    • AppIntentTimelineProvider<\/strong>: provides the data models to build the view, multiple models can be provided which are published according to a timeline.\n
        \n
      • func placeholder<\/strong>: provides a minimal data model while the widget is loading (almost never visible)<\/li>\n
      • func snapshot<\/strong>: provides a data model for when the widget is shown in the gallery as a preview and when first added to the screen<\/li>\n
      • func timeline<\/strong>: provides a single data model (or a collection) for normal use, this is the main source where all data models for the widget come from<\/li>\n<\/ul>\n<\/li>\n
      • TimelineEntry<\/strong>: the data model instance<\/li>\n
      • View<\/strong>: the visual elements of the widget<\/li>\n
      • WidgetConfigurationIntent<\/strong>: enables an end-user to configure the widget, in timeline()<\/code> of the AppIntentTimelineProvider you receive these settings so they can be processed into the data model when needed<\/li>\n<\/ul>\n

        Managing models or any other data in memory, like cache systems or just simple static fields, makes little sense. An iOS Widget is a static object that lives very briefly to perform very small action. In the AppIntentTimelineProvider the functions are invoked almost at the same time but they really run as distinct processes. For exchanging and storing data it is best to use some form of local storage (covered later).<\/p>\n

        App Icons<\/h3>\n

        Previously I had recurring problems with the widget showing wrong icons on different views. Since I explicitly added the AppIcon images to Assets in the Widget extension and referencing them in its info.plist I had almost no problems. If icons are still wrong after updating the assets and info.plist, reboot your test device because iOS seems to do some kind of icon caching with Widgets.<\/p>\n

        In Xcode the AppIcon Assets are predefined in the Widget project. When you open the AppIcon Assets page and then open the Attributes Inspector (top right) you can select iOS ‘All Sizes’. This gives you the ability to set all image sizes. Personally I find that too much manual work, so I use an online iOS icon generator that produces all formats and copy them straight into the Assets.xcassets\/AppIcon.appiconset<\/code> folder.<\/p>\n

        To adjust the plist settings, open the widget extension’s Info.plist<\/code> outside of Xcode (e.g. in VS Code) and insert the entries below inside the NSExtension<\/code> section:<\/p>\n

        <key>NSExtensionPrincipalClass<\/key> \n<string>MyWidgetExtension.MyWidgetBundle<\/string>\n<key>CFBundleIcons<\/key>\n<dict>\n <key>CFBundlePrimaryIcon<\/key>\n <dict>\n  <key>CFBundleIconFiles<\/key>\n  <array>\n   <string>AppIcon<\/string>\n  <\/array>\n  <key>UIPrerenderedIcon<\/key>\n  <false\/>\n <\/dict>\n<\/dict>\n<key>CFBundleIconName<\/key>\n<string>AppIcon<\/string><\/code><\/pre>\n
        Adjust NSExtensionPrincipalClass using the following format:<\/p>\n
        <key>NSExtensionPrincipalClass<\/key>\n<string>{YourWidgetModuleName}.{YourWidgetName}<\/string>\n\n<!-- YourWidgetModuleName can be found in: Extension > Build Settings > Product Module Name -->\n\n<!-- YourWidgetName is the name of the Widget bundle, like \u2018MyWidgetsBundle\u2019 in: -->\n<!-- @main -->\n<!-- struct MyWidgetsBundle: WidgetBundle { --><\/code><\/pre>\n
        Creating a release build of the Widget<\/h3>\n
        Release builds are easy to make in Xcode, but finding the right settings can be a hassle for me. Therefore, I use a standard script that makes it much easier to collect the releases into a dedicated folder, which can also be used in build pipelines. I run this script from the root of the Xcode projects and the releases go to an XReleases<\/code> folder, the X to prevent them from being excluded by the default Visual Studio .gitignore<\/code>.<\/p>\n
        rm -Rf XReleases\n\nxcodebuild -project XCodeWidgetExample.xcodeproj \\\n-scheme \"MyWidgetExtension\" \\\n-configuration Release \\\n-sdk iphoneos \\\nBUILD_DIR=$(PWD)\/XReleases clean build\n\nxcodebuild -project XCodeWidgetExample.xcodeproj \\\n-scheme \"MyWidgetExtension\" \\\n-configuration Release \\\n-sdk iphonesimulator \\\nBUILD_DIR=$(PWD)\/XReleases clean build<\/code><\/pre>\n
        Adding the Widget release to the MAUI app<\/h3>\n
        The widget build output is an .appex<\/code> (a magic macOS bundle folder, similar to an .app<\/code>). On Windows with Visual Studio I previously had much build errors where the appex couldn’t be found. To avoid this I now place the release outputs under Platforms\/iOS\/<\/code> and include them with CopyToOutput<\/code>.<\/p>\n
        Use the snippet below in your .csproj<\/code> to get the files available for the build:<\/p>\n
        <ItemGroup Condition=\"$(TargetFramework.Contains('-ios'))\"> \n   <Content Remove=\"Platforms\\iOS\\WidgetExtensions\\**\" \/>\n   <Content Condition=\"'$(ComputedPlatform)' == 'iPhone'\" Include=\".\\Platforms\\iOS\\WidgetExtensions\\Release-iphoneos\\MyWidgetExtension.appex\\**\" CopyToOutputDirectory=\"PreserveNewest\" \/>\n   <Content Condition=\"'$(ComputedPlatform)' == 'iPhoneSimulator'\" Include=\".\\Platforms\\iOS\\WidgetExtensions\\Release-iphonesimulator\\MyWidgetExtension.appex\\**\" CopyToOutputDirectory=\"PreserveNewest\" \/>\n<\/ItemGroup><\/code><\/pre>\n
        Now add the Widget extension to the .NET MAUI app project. The ItemGroup below ensures that this is done during the build, pay attention to the paths and filenames because this is very strict.<\/p>\n
        <ItemGroup Condition=\"$(TargetFramework.Contains('-ios'))\">\n   <!-- the appex folder path without the platform suffix -->\n   <AdditionalAppExtensions Include=\"$(MSBuildProjectDirectory)\/Platforms\/iOS\/WidgetExtensions\">\n      <!-- the appex file without the .appex suffix -->\n      <Name>MyWidgetExtension<\/Name>\n      <!-- the appex folder platform suffixes -->\n      <BuildOutput Condition=\"'$(ComputedPlatform)' == 'iPhone'\">Release-iphoneos<\/BuildOutput>\n      <BuildOutput Condition=\"'$(ComputedPlatform)' == 'iPhoneSimulator'\">Release-iphonesimulator<\/BuildOutput>\n   <\/AdditionalAppExtensions>\n<\/ItemGroup><\/code><\/pre>\n
        At this point the Widget should be visible in your .NET MAUI app build. Right now it is a Widget that works entirely on its own, without data or communications from your .NET MAUI app.<\/p>\n
        <\/i>Note<\/strong><\/p>Widget extensions will most likely not be visible when you build from Visual Studio for ‘iOS Local Devices’.<\/div><\/p>\n
        Data sharing between App and Widget<\/h2>\n
        iOS Widgets can best be treated as standalone apps. The .NET MAUI app and the Widget can not freely exchange data or communicate. For data exchange we can use .NET MAUI Preferences which maps to UserDefaults on iOS. To ensure they use the same source, both projects need an Entitlements.plist<\/code> specifying the same Group ID which we created earlier when setting up the Bundle ID with App Groups capability.<\/p>\n
        An example Entitlements.plist<\/code> with group id group.com.enbyin.WidgetExample<\/code>:<\/p>\n
        <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<!DOCTYPE plist PUBLIC \"-\/\/Apple\/\/DTD PLIST1.0\/\/EN\" \"http:\/\/www.apple.com\/DTDs\/PropertyList-1.0.dtd\">\n<plist version=\"1.0\">\n  <dict>\n  <key>com.apple.security.application-groups<\/key>\n  <array>\n  <string>group.com.enbyin.WidgetExample<\/string>\n  <\/array>\n  <\/dict>\n<\/plist><\/code><\/pre>\n
        For clarity: both the Widget Xcode project and the .NET MAUI project must use such entitlements, and do not forget to create a new release of the Xcode project after adding the entitlements. Additionally the entitlements of the Widget Xcode project must also be referenced in the .NET MAUI project under the AdditionalAppExtensions<\/code> element in the .csproj<\/code> for the .NET MAUI build.<\/p>\n
        <ItemGroup Condition=\"$(TargetFramework.Contains('-ios'))\">\n   <!-- the appex folder path without the platform suffix -->\n   <AdditionalAppExtensions Include=\"$(MSBuildProjectDirectory)\/Platforms\/iOS\/WidgetExtensions\">\n      <!-- the appex file without the .appex suffix -->\n      <Name>MyWidgetExtension<\/Name>\n      <!-- the appex folder platform suffixes -->\n      <BuildOutput Condition=\"'$(ComputedPlatform)' == 'iPhone'\">Release-iphoneos<\/BuildOutput>\n      <BuildOutput Condition=\"'$(ComputedPlatform)' == 'iPhoneSimulator'\">Release-iphonesimulator<\/BuildOutput>\n\n      <!-- entitlements for the appex, without this the shared storage won't work -->\n      <!-- errors that entitlements could not be found: include the entitlements with CopyToOutput -->\n      <!-- errors when reading entitlements during build: store entitlements file with line-ending type LF -->\n      <CodesignEntitlements>Platforms\/iOS\/Entitlements.MyWidgetExtension.plist<\/CodesignEntitlements>\n   <\/AdditionalAppExtensions>\n<\/ItemGroup> <\/code><\/pre>\n
        At this point the App and Widget should be able to use the same data source. In both projects the usage of a specific Group ID must be indicated explicitly in code. In .NET MAUI do NOT use Preferences.Default<\/code>; instead provide the Group ID in the sharedName<\/code> parameter.<\/p>\n
        \/\/ example how to store data in .NET MAUI.\nPreferences.Set(\"MyDataKey\", \"my data to share\", \"group.com.enbyin.WidgetExample\");<\/code><\/pre>\n
        \/\/ example how to store data in Swift.\nUserDefaults(suiteName: \"group.com.enbyin.WidgetExample\")?.set(\"my data to share\", forKey: \"MyDataKey\")\n\/\/ example how to get data in Swift.\nlet data = UserDefaults(suiteName: \"group.com.enbyin.WidgetExample\")?.string(forKey: \"MyDataKey\")<\/code><\/pre>\n
        <\/i>Note<\/strong><\/p>Storage keys are case-sensitive; I advise to keep keys simple and optionally consistently lowercase to avoid problems.<\/div><\/p>\n
        Communication from App to Widget<\/h2>\n
        The Widget does not know when the App shares data and the App does not know when the Widget does so. Signaling new available data from the App to the Widget uses a different mechanism than from Widget to App. Signaling from App to Widget is easy with Apple’s WidgetKit API. This API is not available in .NET MAUI so you must create a binding yourself. It is a very small API and great to experiment with bindings yourself. For this demo I use a NuGet package WidgetKit.WidgetCenterProxy<\/code> where this has already been done for us.<\/p>\n
        The WidgetKit API mainly provides two options: reload all widgets on the device or reload only widgets of a specific kind<\/code>. I always use the latter because the platform will ignore you if you use one of these options too frequently; I imagine they also prefer that you only update your own specific widgets. The kind<\/code> of your Widget is easy to find in your Widget object in Swift; under the kind<\/code> property.<\/p>\n
        \/\/ Example on how to refresh all Widgets of kind \u2018MyWidget\u2019 in .NET MAUI\nvar widgetCenterProxy = new WidgetKit.WidgetCenterProxy();\nwidgetCenterProxy.ReloadTimeLinesOfKind(\"MyWidget\");<\/code><\/pre>\n
        <\/i>Note<\/strong><\/p>WidgetKit reload functions are a polite request to the OS; it decides when it happens and whether you are using it too often. Usually the widget refresh happens immediately.<\/div><\/p>\n
        Communication from Widget to App<\/h2>\n
        Communication from Widget to App can happen in two ways, optionally with a very small amount of data. By default a Widget opens the corresponding app when you tap it, if you overwrite this with widgetUrl()<\/code> you can open the app with a Deep Link that includes data in the url. A drawback is that a Widget is build as a static object, when using widgetUrl<\/code> the URL must be determined beforehand when setting up the Widget view (often happens in the provider) and passed as string through the data model.<\/p>\n
        \/\/ example of using a DeepLink URL in Swift\nstruct MyView: View {\n   var body: some View {\n      \/\/ my views\n   }.widgetURL(URL(string: \"mywidget:\/\/something?var1=dummy-data\"))\n}<\/code><\/pre>\n
        A different way to communicate can originate from AppIntents. An AppIntent is a way to execute actions\/logic that you can attach to interactive elements like buttons. It is also the place where the OS gives you a bit of time to perform long-running actions, like for making http calls. When you combine local storage with AppIntents you can create a full ‘Interactive Widgets’, as shown in the rendering cycle image below.<\/p>\n
        \"Widget<\/p>\n
        For example you can attach a custom AppIntent to a button in your Widget that changes a value in storage, after which the AppIntent itself triggers a refresh of the Widget. The system reloads the widget by calling AppIntentTimelineProvider, creating a new data model (timeline entry) and re-rendering the view with the updated data.<\/p>\n
        \/\/ example of an AppIntent changing data and reloading widget\nstruct IncrementCounterIntent: AppIntent {\n   static var title: LocalizedStringResource { \"Increment Counter\" }\n   static var description: IntentDescription { \"Increments the counter by 1\" }\n\n   func perform() async throws -> some IntentResult {\n\n   var currentCount = 0\n\n   let userDefaults = UserDefaults(suiteName: Settings.groupId)\n   let storedValue = userDefaults?.integer(forKey: Settings.appIncommingDataKey)\n   if let storedValueCount = storedValue {\n      currentCount = storedValueCount\n   }\n\n   \/\/ do action\n   let newCount = currentCount + 1\n\n   \/\/ Save new value\n   userDefaults?.set(newCount, forKey: Settings.appIncommingDataKey)\n\n   \/\/ Reload timelines > refreshing widget\n   WidgetCenter.shared.reloadTimelines(ofKind: \"MyWidget\")\n\n   return .result()\n}<\/code><\/pre>\n
        \/\/ example of Button using AppIntent in Swift\nstruct MyWidgetView : View {\n   var entry: Provider.Entry\n\n   var body: some View {\n      VStack(spacing:4) {\n         Button(intent: IncrementCounterIntent()) {\n            Text(\"+\")\n         }\n      }\n      .padding()\n   }\n}<\/code><\/pre>\n
        Silent communication from Widget to App<\/h3>\n
        On iOS, a Widget can NOT communicate with the App in the background. Any direct call brings the App to the foreground. To keep the App closed and still perform work, you can use AppIntents in the Widget to call your backend. The backend can execute the action and, if needed, send a silent push notification to the App. The App can then handle the update in the background if required. This can be done with any web service and existing push notification provider; For that reason, I’ve included only an illustrative SilentNotificationService as entry point in the demo code rather than a full implementation.<\/p>\n
        Create a configurable Widget<\/h2>\n
        Because I selected the ‘Configuration App Intent’ option when creating the Xcode Widget extension, there is already a working system in place that allows the user to configure the widget. In the loop of creating the data model in AppIntentTimelineProvider<\/code>, this configuration becomes available and can be processed into the data that is passed to the Widget view. It’s a simple basic system that’s all implemented in a WidgetConfigurationIntent<\/code> that is specified in the WidgetConfiguration<\/code> for the specific Widget.<\/p>\n
        struct MyWidget: Widget {\n   let kind: String = \"MyWidget\"\n\n   var body: some WidgetConfiguration {\n      AppIntentConfiguration(kind: kind, \n      intent: ConfigurationAppIntent.self,\n      ...<\/code><\/pre>\n
        Visually, there is nothing to customize in the WidgetConfigurationIntent. You only need to add ‘@Parameter’ fields for the settings you want users to configure; the platform handles the UI automatically.<\/p>\n
        struct ConfigurationAppIntent: WidgetConfigurationIntent {\n   \/\/ title: mainly for Siri\/shortcuts, keep it simple if you don't use Siri\n   static var title: LocalizedStringResource { \"Configuration\" }\n   \/\/ description: mainly for developers in the app intents system, users will never see this \n   static var description: IntentDescription { \"This is an example widget.\" } \n\n   \/\/ An example configurable parameter.\n   @Parameter(title: \"Favorite Emoji\", default: \"\ud83d\ude03\")\n   var favoriteEmoji: String\n}<\/code><\/pre>\n
        Most built-in types can be used with @Parameter, such as String, Int, Bool, Date, etc. For more complex types like lists or custom objects, a separate type can be created that implements AppEntity<\/code>. This is a somewhat more extensive topic that I won’t cover completely here. The principle is simple: the AppEntity object is a selectable datamodel that provides its own options through an EntityQuery<\/code>. This EntityQuery delivers a collection of AppEntity objects from which the user can choose. It’s important to know that the platform can iterate through the different functions of the EntityQuery multiple times, and again these functions have difficulty exchanging data with eachother. My advice is to use local storage (UserDefaults) to cache and exchange data between the different functions.<\/p>\n
        Wrapping Up and Practical Tips<\/h2>\n
        With the interactive widget fully implemented, the next step naturally becomes refining your logic, layout, and overall design. While most of your core logic can remain inside your .NET MAUI app for reuse across platforms, a bit of Swift will always be required for widget specific tasks like handling storage, building views, or performing lightweight backend actions. Here are some final tips to help you get up to speed during the transition from C# to Swift:<\/p>\n
          \n
        • Use VS Code to pair-program with Copilot when creating your Swift code.<\/li>\n
        • Keep Xcode open for rapid build and preview cycles to catch issues early.<\/li>\n
        • Open the Canvas view in Xcode and use #preview data so you can see visual changes quickly.<\/li>\n<\/ul>\n
          If you’re interested in taking your widget skills to Android, good news: an article on building Android Widgets with .NET MAUI is coming soon. Stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":"
          Build professional iOS widgets with .NET MAUI, from static displays to interactive widgets.<\/p>\n","protected":false},"author":201971,"featured_media":59323,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685,7812,7233],"tags":[7238,7245,8111,8108,8110,8109],"class_list":["post-59146","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","category-dotnet-ios","category-maui","tag-net-maui","tag-ios","tag-mobile-development","tag-swift","tag-widgets","tag-xcode"],"acf":[],"blog_post_summary":"
          Build professional iOS widgets with .NET MAUI, from static displays to interactive widgets.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/59146","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/201971"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=59146"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/59146\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/59323"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=59146"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=59146"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=59146"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}