On December 6th, 2018 iOS 12.1.1 came out and now requires that all publicly-trusted Transport Layer Security (TLS) server authentication certificates issued after October 15th, 2018 meet the Certificate Transparency policy to be trusted on Apple's platforms. This will mean that all certificates used in iOS applications will need to include two signed timestamps by a certificate transparency log to be trusted in your application. If these CT log timestamps are not present than this could mean that the TLS connections in your application is deemed un-trusted and will not work. This is an excellent step forward in iOS network security. This means that going into 2019 you can have a higher level of trust in connections that are coming from devices running iOS because their CT logs are known publicly and trusted throughout the network security community.
The Android platform does contain many similar network security features, but nothing like adhering to a Certificate Transparency policy. For example, on Android you can create a configuration file that defines a select number of Certificate Authorities that only your application trusts to make secure connections with. You can also perform SSL pinning to make sure that your app's secure connections are only made with a specific certificates. Some developer's view Android's network security options as modular and liberating; allowing developers to only apply what is needed and not having to get hung up in restrictions that may not apply for their application. I fall into the camp that the more baked in security for your application the better. Android does have some nice network security features, but the security of the application is totally reliant on the developer to set it up. iOS 12.1.1 will enforce Apple's Certificate Transparency policy out of the box without developer configuration and will eliminate the need for developers to accidentaly miss a configuration.
What is Certificate Transparency and Why Does it Matter?
Certificate Transparency is the process by which certificate logs are made publicly available by auditors for proof or validation of certificates being used in SSL/TLS connections. When a client makes a connection with a server an audit log is kept of that connection and the certificated used. Periodically a monitor reaches out to the auditing entity and evaluates the logs for non-trusted certificates. These non-trusted certificates could be used to spoof the identity of an individual or perform a man in the middle attack. When a monitor detects a suspicious certificate on the auditor this certificate can be flagged as un-trusted and can be refused by the handshake the next time the connection is made. This public process of sharing legitimate certificate logs attempts to eliminate the rough certificates by making them publicly known.