I started this blog back in September of 2013. With the 5th Anniversary this month, I figured it is time to tell some of the story..

First languages

My first programming language was APL, which I partly learned in high school as a small part of Mathematics classes. This lead to me becoming part of what was called “Computer Club”, where a teacher gave up part of his lunchtime to help students learn about computer programming. The teacher also introduced us to BASIC, and when devising our programs we would fill out computer “cards” that would be sent to a computer centre in our capital city (Adelaide), where the cards would be read by a card reader, the computer would execute the programs, and we would receive a print of the results; a complete turnaround time of about a week!

Enter Pascal

Not long after I learned of Pascal, and instantly fell in love with it. One of my first experiences with it was writing programs on my father’s computer using a BASIC program that would be able to take Pascal source, and execute that (from memory, it would turn it into assembler code).

The first computer of my own was a Microbee (which runs the CP/M OS). One of the reasons I chose it was because at the time I predicted that the IBM (and various clones) would not take off (how wrong was that call?). On that computer I used Turbo Pascal 2.2 for CP/M, and back then there was no concept of units. In order to have larger programs, you would need to use what were called “overlays”. Version 4 was a total game-changer, however by the time I upgraded (to 5.5) I had moved on to owning a PC, which I initially considered heresy!

Turbo Pascal for Windows: the “father” of Delphi

When Windows first came out, I also figured that wouldn’t last, because it looked too clunky. I mean: what’s with not being able to have windows overlap each other? This time Windows 3.1 was a game changer because it was far less crash-prone, introduced True Type fonts, included drag-and-drop, and more! I knew then that I should delve into the magical world of Windows programming.

Soon after the release of Windows 3.1 came Turbo Pascal for Windows 1.5. When I started using it, all I could think was “Wow, I can write programs for Windows in my favourite language!”. One of the first things I wrote with TPW was a basic card game, based on “Switch” (a bit like Uno), which I enjoyed playing with my brothers. Unfortunately however, writing apps for Windows with TPW meant having to write way more code than I was used to.

Enter Visual Basic: a development tool that not only allowed you to write for Windows, it was way easier because you could design everything visually, and it didn’t require as much code to write. Around mid-late 1993, I reluctantly started to write programs with VB, in the hope that sometime soon the magicians at Borland would come up with something even better.

Entering the world of Delphi

Around January of 1995, I heard (or read?) rumours that Borland were on the cusp of releasing something akin to VB, and it was being dubbed the “VB killer”. I was a bit cynical at the time, however of course on February 14th, 1995, Delphi was released upon the world, and it certainly lived up to my expectations: it had a visual designer, ready-made components, and it also supported importing VB controls! I figured I would never, ever have to use VB again, though briefly in 1998 I had to endure working on a project that used it.

That’s the story of how I came into developing software with Delphi. At first it was a hobby, though I did use it to some extent “under the radar” at my work between 1995-1997, until I turned professional in 1997 and since then I have used it every single year (though not every single release, but most of them).

Enter Delphi Worlds blog

Fast-forward to 2013, and after posting blog articles elsewhere, and only very occasionally, I decided to start my own blog, hosted on my own site. When I came up with the name, I thought about the fact that Delphi was now cross-platform, and that opened up a number of new “worlds” for developers.

One of my first criteria for the blog was (and still is): no ads. I was disillusioned with having to read articles other sites that had ads plastered all over because they just add too much noise. My main aim is to share what are “challenges” to developers that they might otherwise spend ages having to work out how to implement. Having said that, they are usually also of special interest to me, i.e. they’re something that I’ve had to solve for myself.

Time…

Nearly all of the time spent on the articles I present here is my own, i.e. I’m not compensated in any way for it (especially with no advertising here). As much as I do this out of my passion for Delphi and to help others, there is now another way to help motivate me, and that is through the “Donate” link at the top right of this page, and at the bottom of this article. Your donation can be as little or as much as you wish, and whatever the amount is, it will be much appreciated, and help continue my work here.

I thank you for your support and your time.

It’s time to become excited, because Delphi 10.3 Rio has been released!

Rather than go over all the new features here, please refer to the Embarcadero website, and the docwiki for a full list.

Of special interest to me are:

• The out-of-the-box support for Android API 26+, so if you’re using Rio, there’s no longer any need for my special workarounds as per my earlier articles.
• Android Native Controls and FMX styled controls on the same Android form.
• Improvements in the IDE: I like the new look, though the invasion of the “space monster”* will likely upset those who like to have their systems in larger scale, or those who use lower resolution monitors (such as with some projectors). I’ve also moved over to the “dark side” because the dark theme support is looking better.
• iOS 12 support.

If you prefer ESD (Web) install go here, for ISO go here, and here for a full list of the fixed issues.

(*”space monster” refers to the amount of extra spacing that has been added in some places in options dialogs)

Codex 1.1.0 for Delphi 10.3 Rio

With the release of Delphi 10.3 Rio comes the release of Codex 1.1.0, which also has support for Delphi 10.2 Tokyo, however support for Delphi 10.1 Berlin has been dropped. (Codex 1.0.0 has support for Berlin and Tokyo)

New features:

• LogCat viewer – no more need to run Monitor to see what’s going on in your device! More filtering options will come later..
• Java2OP “front end” – run the Java2OP import tool from right in the IDE!
• SDK Frameworks Import – The ability to add multiple frameworks at once, into an existing SDK in the SDK Manager, or into the SDK defaults
• Option to show the project manager when opening a project or group

Check out the full list of features, and how to download.

On February 14th, 1995, Delphi was brought into the world, and it changed the software development landscape. Now 24 years later, Delphi is still going strong, with the ability to target multiple platforms from single source.

This milestone is being celebrated with the release of the first update to Delphi 10.3 Rio, which contains a number of enhancements and fixes to over 150 user reported issues.

Fixes of special interest to me are:

• Notifications for iOS >= 10
• Linking of newer versions of some third-party iOS SDKs (e.g. Firebase and Facebook) to iOS 12 SDK
• Use of 9-patch images on Android
• Warning toast on Android 9
• ..and a bunch of other fixes for FMX issues

Head over to the official announcement for more details.

A recent report on Embarcadero’s Quality Portal caught my attention today, where an app would crash if it used a TMapView on an Android 9 device. Fortunately, I had just recently updated my Nexus 5X to Android 9 (thanks to Brian Long’s help), so I could investigate the problem.

First thing to do was to create a new project, place a TMapView on the form, populate the apiKey value in the project options:

..and check the Maps Service checkbox in the Entitlements section:

Next, I fired up Monitor, which comes with the Android SDK tools (run monitor.bat, which is in the tools folder from the root of the Android SDK) and start the Android app. Lo and behold, when the app crashed, the logcat messages indicated an error:

A quick Google of the error (searching on “Failed resolution of: Lorg/apache/http/ProtocolVersion”) revealed a discussion on StackOverflow, and more importantly, what to do about it. The solution is incredibly simple: just add a tag to the AndroidManifest.template.xml:

the text is:

  <uses-library android:name="org.apache.http.legacy" android:required="false" />

..and all is good in the world again!

Yesterday, I uploaded a new version of Codex to the Github repository that has the installers.

Main new changes in this version:

Editor Tabs Position

There’s now an option (in Tools->Codex->Options) to have the editor tabs (e.g. Code | Design | History) appear on the left, just like they used to! If you also have CnWizards installed, you will need to disable the FeedReader Wizard (Tools->CnPack->Options, Wizard Settings) in order for the editor tabs option to work consistently, until CnWizards is fixed. The editor tabs option has the odd quirk where the tabs may not always appear on the left, however I’m working on resolving this in the next update to Codex.

Feed Alerts

Monitors feeds (Atom or RSS) that you’d like to be “alerted” about, such as new entries in the Embarcadero Quality Portal, or on Code Central (such as updates to Delphi), or perhaps new questions about Delphi on StackOverflow.

Updated Image Assets feature

The Image Assets feature has been updated to support the changes in Delphi 10.3.1 regarding splash and icon image sizes for iOS.

Happy coding!

Codex had a feature where you can launch a logcat viewer for displaying logs for Android devices. This feature has now been moved out of Codex (in version 1.2.1)  into a separate application: Device Lens

Device Lens 1.0.0 has just been released, and you may find it here. There is some basic documentation at the link, however if you have questions or issues, please create an issue at this link.

At present, Device Lens provides displaying of logs for Android devices, however Device Lens 1.1.0 is planned to be able to display log messages for iOS devices. This would be made possible by Device Lens communicating with the macOS companion application: Mosco, so that your iOS devices can remain connected to the Mac, and be able to debugged using Delphi at the same time.

As per the title of this post, Codex 1.2.1 is also released (this release is for Delphi Rio 10.3.x only), which includes a few bug fixes.

The requirement for macOS apps to be notarized has thrown a few challenges, one of them being that developers are having trouble with apps that use Indy components with SSL. This article describes how to overcome that issue.

Rather than dive headlong into working out why the notarized app would not work, I decided to “start from scratch” (in a way), and work out how to build the dylibs for macOS. The results are located here (i.e. macOS binaries for OpenSSL, version 1.0.2s).

The binaries need to be added to your application via the Deployment Manager, and the Remote path value for each binary is: Contents\MacOS, e.g:

Note that in this picture, I have selected All configurations for macOS 64-bit, so that both Debug and Release are shown.

In the project source, add System.IOUtils and IdSSLOpenSSLHeaders to the uses clause, and call IdOpenSSLSetLibPath, like this:

program NotarizedIndy;

uses
  System.StartUpCopy,
  System.IOUtils,
  FMX.Forms,
  IdSSLOpenSSLHeaders,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}

begin
  IdOpenSSLSetLibPath(TPath.GetDirectoryName(ParamStr(0)));
  Application.Initialize;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

After compiling and notarizing your application, you should find that Indy with SSL now works.

Previously, I have written two articles on monitoring location changes: one for iOS, and one for Android. This article and the related demo brings everything up-to-date and merges support for both operating systems.

STTP (Straight To The Point – I’m coining an acronym to replace TLDR)

If you’re just after the demo, you may find it here. As with most demos in the articles in this blog, it is dependent on the Kastri Free library. Please be aware that for iOS you will need to apply the System.iOS.Sensors patch as detailed below.

Requirements

As per the previous articles, the aim is to be able to monitor location changes reliably, including when the application is not running. Due to restrictions introduced in later versions of Android, and some shortcomings in the iOS implementation in Delphi, there some “hoops to jump through” to make this all happen.

Project Groups

The demo has 2 project groups: one containing the application and service (CPLAndroidGroup), and one that contains just the application (CPLAppOnlyGroup). CPLAppOnlyGroup is useful for compiling for iOS, because if you compile just the application in the CPLAndroidGroup for iOS, the IDE will still compile the service, regardless of the fact that you are not compiling the application for Android. This issue has been reported, here.

Grijjy Cloud Logger

You may notice in the code that use is made of the excellent Grijjy Cloud Logger framework. This has been useful for debugging so I have left the code in, and if you want to use it, you will need to add defines (CLOUDLOGGING) in the Project Options for the supported platform targets.

Unfortunately at present there is no support for Grijjy Cloud Logging on Android 64-bit. Hopefully this will be rectified soon.

If you choose to use Grijjy Cloud Logging, you will need to either define user override environment variables in the IDE options that correspond to the library locations:

• $(Grijjy) refers to Grijjy Foundation
• $(ZeroMQ) refers to ZeroMQ for Delphi

..or modify the project search paths to point to the required libraries.

You will also need to modify the value for cCloudLoggingHost in the CPL.Consts unit in the Common folder, to point to your cloud logging broker instance.

Application

The application has been refactored to integrate the iOS implementation to make things work smoother, and hopefully be easier to follow. Notably, it now includes the DW.ServiceCommander.Android unit, which contains:

TServiceCommander

This class:

• Handles the BecameActive and EnteredBackground application events, sending a local broadcast to the service to inform it of the change so that the service can enter or exit foreground mode.
• Has a StartService command that starts the service if it is not already running.
• Has a SendCommand method to send any other commands that the service needs to receive.

DW.Location unit

This unit and the units it uses contain the classes necessary for integrating iOS support, and for Android for receiving location messages from the service. The iOS implementation uses TLocationSensor which comes with Delphi, however there are some customizations that are necessary, which are detailed later in this article.

Android Service

On Android, the application needs a service, and since it needs to be able to track location when the app is not running, it needs to start when the device starts. As per the previous Android demo, instead of using TLocationSensor, I chose to write custom code; mostly for more control, and also so that it can be easily “swapped out” for another implementation such as one that uses FusedLocationProviderClient.

The ServiceModule has been refactored to decouple some of the functionality, namely:

TBackgroundMonitor

The OnScreenLockChange event is fired when the screen is locked.

When the device enters “doze” mode, an alarm is set so that the service will be invoked when the alarm fires, and the OnDozeChange event fires so that any additional action may be taken.

TLocationUpdater

This class is responsible for processing the location update. It may send the location details to a server, and/or store the location in a local database.

TLocation

This class existed in the prior version of the demo, however it has been refactored somewhat to improve reliability.

Starting the service at boot time

The service starts when the device starts by using a broadcast receiver (A Java class called DWMultiBroadcastReceiver, in dw-kastri-base.jar) which is configured in AndroidManifest.template.xml

The android.intent.action.BOOT_COMPLETED and android.intent.action.QUICKBOOT_POWERON intent filters ensure that the broadcast receiver receives these intents on cold boot and restart. In the Java code for DWMultiBroadcastReceiver, the metadata is checked for an entry named DWMultiBroadcastReceiver.KEY_START_SERVICE_ON_BOOT, and the metadata value is used as the name of the service to start:

Note that DWMultiBroadcastReceiver also exists in dw-multireceiver.jar, however I am in the process of merging Java code used in Kastri Free in an effort to reduce the number of jar files.

Considerations for later versions of Android

In Android 10, using location services via a service requires requesting a runtime permission of android.permission.ACCESS_BACKGROUND_LOCATION, so this permission is added to AndroidManifest.template.xml (the permission cannot be  configured via the IDE), and the permission is requested in code.

From Android 8, a service is required to start in foreground mode if the application goes to the background or is not running. The previous demo went some way to solving this, however it was not 100% reliable; this demo should work as it should. Since the demo uses a regular service, when starting in the foreground the service needs to post a notification which is visible in the status bar, and a banner is visible in the lock screen. Although this is a tad intrusive, presently it’s the only option using a plain Service constructed in Delphi, as using an Intent Service is currently broken in Delphi.

iOS

Delphi implementation issues

As per the previous article about location monitoring on iOS, the main issue is that using TLocationSensor “out of the box”, location updates do not occur when the application is in the background or the application is not running. The easiest way to solve this was to patch the System.iOS.Sensors unit, which uses code from the DW.iOS.Sensors unit to help manage the usage (e.g. When In Use and Always), background status (normal and significant changes) and activity (such as Auto and Fitness).

Applying the System.iOS.Sensors unit patch

The easiest way to apply the patch is with Codex, using the Source Patcher function:

If you have not already installed the Patch executable, there is a download link in the Source Patcher dialog:

After downloading/installing, you will need to change the name of the executable to something other than patch.exe (such as p.exe), as Windows thinks it is some kind of installer and will not run without elevated privileges.

Select the patch executable, source file, patch file, and destination folder, e.g:

The System.iOS.Sensors.10.3.3.patch file is supplied with the demo in the Patches folder

The patched code in the resulting file is indicated by comments beginning with // DW, so they’re easy to find.

Testing the demo

I would like to have done more testing on this demo than I have (so far), however it can be rather time consuming, since some of the “live” testing requires physically moving from place to place. I’d like to once again thank Atek Sudianto from Jakarta, for running this demo through its paces.

Android

Normally a device will not go into “doze” mode until a couple of hours of inactivity, when not connected to any charging source. This can make it difficult to debug since debugging normally requires the device to be plugged in to the computer doing the debugging, however I stumbled across a technique for “faking” doze mode. Long story short: it’s via an adb command, and I have now integrated this function into Device Lens:

As pictured, click the “minus” button to fake doze mode, and the “plus” button to restore it to normal.

To test the service starting at boot, either turn the device off, then back on again, or use the device’s reset facility. Shortly after the device starts, you should see the notification icon for the app (default is the Firemonkey icon) in the status bar. This is because the service has started in foreground mode, which requires a notification being displayed.

If you then start the application, you should see the notification icon disappear, because the service has exited foreground mode.

iOS

Location updates on iOS when the app is in the background or not running have been exceedingly frustrating (regardless of the issues in Delphi) ever since I’ve started using them. When first testing this new demo, I found that it did not appear to be generating updates, despite the device having moved significantly (more than 500 metres, apparently), then after a while (a day or so), location updates started happening (there were no code changes), without the device moving significantly.

I’d be interested to hear from others about their experiences with background location updates on iOS (using their own code or the demo from this article), so please feel free to leave a comment.

Looking to the future

I have been working on an implementation of location updates that uses FusedLocationProviderClient, however it has been left out for now due to time constraints.

I am also looking into solving the intrusive notification that shows when the service is in the foreground on Android. Indications are that a JobIntentService should be used, however as described earlier this is currently broken in Delphi, though I am looking into solving that issue, as well as investigation other methods.

Finally, hopefully the location services issues for iOS in Delphi will be solved in Delphi 10.4, removing the need to patch the Delphi source.

The release of Delphi 10.4 Sydney is just around the corner. I’ve specifically been given permission to show updates and new features in the product, so let’s get to it..

Note: This is pre-release information

As such, any or all of it may change. Please check the What’s New when the product is officially released.

API enhancements and fixes

One of the things you may notice is that there have been fixes to existing APIs on macOS, and additions to APIs on macOS and iOS. In particular, there’s been a number of methods added to imports of Objective-C classes that developers have been asking for, such as for NSNotificationCenter and NSObject.

In Delphi 10.4 Sydney, the dependence on QTKit has now been totally removed – no more annoying warnings when uploading to the macOS App Store, and a couple of issues regarding permissions have now been solved.

Improvements to existing components

The implementation for TWebBrowser on macOS and iOS has now been migrated to use WKWebView. This means it now supports playing mp4 files from web pages that are navigated to, and there should be no more warnings when you upload your app to the store.

There are also improvements to TLocationSensor for iOS. 3 new properties have been added (all related to iOS only), namely:

• ActivityType – this property corresponds the to the activityType property for CLLocationManager on iOS
• UsageAuthorization – now you can specify what kind of usage is requested when starting TLocationSensor, i.e. Always and WhenInUse
• OnLocationUpdatesPausedChange event – this notifies when location updates “paused” state has changed.

Also, you should now find that location updates occur when the app is in the background, or when the app is not running, as long as you include location in UIBackgroundModes in the Project Options.

..and much, much more!

The above mentioned changes are just some of many. Please check the blogs of other MVPs, and product managers like Marco Cantu, Sarina Du Pont and David Millington, for more news about Delphi 10.4 Sydney.

Coinciding with the release of Delphi 10.4 Sydney, commercialization of Kastri has morphed into using Github Sponsors to help fund its development. This article details whats changed, whats new, and the future of Kastri.

Kastri Free

Be assured the Kastri Free repo will remain, however all new development will continue in the new Kastri repo.

Github Sponsors

There are 3 tiers of monthly sponsorship and any tier will help support and guarantee the future development of Kastri as well as contribute to enhancing the product as technology changes. All sponsors will have exclusive access to the #sponsors channel in the Delphi Worlds Slack Team where they can participate in making feature suggestions, highlight enhancements and best practices for how they use Kastri and other Delphi Worlds libraries in their development.

 Tier 1 – $5.00

Every developer knows that coding is fuelled by coffee. This level gives you the satisfaction of knowing you’re supporting Kastri and other repos, and allows us to stock the coffee machine. (Please note on Fridays this may go towards beer or a nice red.)

Tier 2 – $20.00

Aimed at those lone developers slaving away on their keyboards and use Kastri or any other repo for commercial purposes. Ideally you’ll have less than 100 users across your products.  Included at this level are 2 priority support incidents* per year.

Tier 3 – $50.00

Choose this tier if you are using my libraries or components in commercial applications and they provide a significant asset among your tools as a developer or organisation. At this level you receive 4 support incidents* per year

*Support incidents are related to the Kastri repo only. Details of how support incidents will be handled are being finalised.

Click Here to start sponsorship of Delphi Worlds

Supported Delphi Versions

Supporting older versions can be time consuming, however more importantly: Kastri revolves mostly around mobile development, and if you’re deploying to the app stores, staying current is essential. Kastri will now support Delphi 10.3 and above only

The New Repo

If you visit the new repo, you’ll find there has been a number of changes from Kastri Free.

• New API import files – including some that will be used in upcoming features
• Renamed/rationalized API import files – some imports have been aggregated, and some have had the file renamed to better reflect what is in it
• ComponentHelpers (which really should have been named Interposers) has been removed and the files moved into Core
• Some of the Demos that were in Kastri Free have not been migrated, because they’re not relevant to Kastri requirements, and some have been revamped (or will be)
• New Features have been added, namely: Biometrics (TouchID/FaceID on iOS and Fingerprint support on Android), and Speech Recognition.
• Files in the Java and ThirdParty folders have been reorganized
• A new folder called Tools that will contain executables used for build automation etc.

Upcoming Features

New features are coming to Kastri, and your sponsorship will help make them a reality sooner. They include:

• Photos library support – a platform agnostic means of managing collections of photos stored on the device, and a Facebook-style photos selector
• Apple Login – implementation of Apple Login that adheres to the App Store guidelines
• Universal Links – support for custom schemes and universal links on iOS
• Camera – a revamp of the original Delphi Worlds Camera project, with support for iOS and Android

Delphi 10.4 Sydney

Kastri has already been tested with Delphi 10.4 Sydney, and is fully compatible.

Sponsor Today!

Click Here to start sponsorship of Delphi Worlds to ensure the future development of Kastri as well as contribute to enhancing the product as technology changes.

If you follow the Codex repo, you would have noticed that version 1.3 was actually uploaded a couple of days ago. This article describes a what’s new and changed in Codex, and things I’m working on for Kastri.

Codex

Editor Tabs On Left

With the release of Delphi 10.4 Sydney came some changes to the IDE, which includes the StatusBar at the bottom of the code editor windows. Those changes in particular broke the “Editor Tabs On Left” feature of Codex. I struggled for a while to make them work again, however the best I could do so far is to have them appear on the left only if the macro toolbar that appears in the extreme left is hidden, and even then when the desktop changes (such as when debugging) it would all fall apart again, so I have shelved that feature in 10.4 for now.

ADB Connect

Codex 1.3 has a new feature: ADB Connect. This allows you to connect to an Android device over a network, as long as your machine can “see” the other address. The option is available via Tools|Codex|ADB Connect, or via the new Codex toolbar that you can enable by right-clicking the Delphi main toolbar and checking the Codex item:

In order to connect to a device via IP, first the device needs to be connected to a machine via a USB cable, then at a command prompt, run this command:

[path_to_adb]\adb tcpip 5555

Where [path_to_adb] is the path to the adb command on the machine, which means it will need to have at least the Android SDK tools installed (i.e not necessarily the whole SDK). This is all made simple via DeviceLens, which can help with installing the Android SDK tools, and actually run the command required to put the device into TCPIP mode:

Once the device is in TCPIP mode, you can use the ADB Connect feature to connect to the device:

The “configure for TCPIP” part could appear in a future version of Codex. ADB Connect was developed in response to being able to debug/monitor a device over a VPN, so the device may not even be in the same country as the machine that has Codex on it.

Total Clean

A menu item has been added to the Project Manager context menu called Total Clean:

This option will remove all files in the projects output folders for every platform as well as the folders themselves (if it can), so please use it when you’re absolutely sure that’s what you want to do.

In the works for Kastri

As per the last article, there are a number of things planned for Kastri. Becoming a Github Sponsor will help make these a reality. I’m currently working on:

Apple Signin support

As per Apple’s guidelines, if you offer login via any of the major social media providers, you must also offer login via Apple Signin (this has applied since April 2020). I have an implementation in testing phase, so if you’re interested in helping out, please join my Slack team and go to the #kastri channel.

Camera for Mobile

A while ago I published this project, which implements the device camera using the newer Camera2 API on Android. I had plans to add iOS support when I started it, and actually had a private project that did implement it on iOS, however I shelved all of it due to time constraints. When joining Github Sponsors, I figured I should include features that would help encourage developers to sign up for sponsorship, so I have resurrected the camera project to be part of Kastri.

Some of the work has been done, including having the camera preview take advantage of the native view implementation included in Delphi so that it has z-order support, e.g. you can have the preview on a tab of a tab control, and switch tabs without having to turn off the preview. Also, because it uses native classes for the preview, performance is way above that of the built-in camera component in Delphi. 

Other items in the works

These items are planned:

• Photos library that makes use of the Photos framework on iOS, and has implementation for Android
• Universal Links support on iOS
• Background Task management for iOS
• Background Fetch for iOS (improved version)
• Sensors (using the OS APIs)

All items currently in the works or planned have a much better chance of becoming a reality and potentially sooner with sponsorship, so please consider becoming a sponsor today!