WiFly/Mikrotik Captive portal page doesn't close on iOS, but works on Android
The automatic handling of captive portals on works by iOS automatically downloading various Apple URLs when connecting to a new network, such as these URLs:

http://captive.apple.com/hotspot-detect.html
  https://www.apple.com/library/test/success.html
  (and others)

If the download contains the word "Success", iOS is satisfied that the user has direct access to the Internet.

If the download contains something else, it is most probably a captive portal page, which requires the user to authenticate in some manner. This triggers the Apple Captive Network Assistant to display the downloaded page on screen.

The user then authenticates in some manner with this page. Afterwards iOS periodically checks those URLs mentioned before to see if it now contains the word "Success". As soon as it does, the CNA window is closed.

This method of detectiing captive portals and authenticating conforms to the WISPr 2.0 specification and allows the so called "Universal Access Method" for authentication. This specification is followed by iOS and Android devices alike.

As this doesn't happen for you, it means that your setup somehow prevents the iOS device from downloading the correct page. This could be due to incorrect cache settings on your proxy server (if you have one), incorrect DNS settings, incorrect authentication checks, etc. Especially it's important that you never block any of the apple.com pages used for captive portal detection.

In some cases you can also have problems, if your captive portal page presents an outdated or otherwise invalid TLS certificate.

Another source of errors is when your system redirects the user to another page when successfully authenticated. This could be to an internal page or an external page. Depending on how your system is setup, one of the two might be failing - so you could switch to the other type, or fix the configuration errors (such as firewall or authentication checks) that prevent the user from accesssing the redirect page.

A good way to check is to use Wireshark to make a packet capture of the WiFi interface when trying to connect. You'll be able to see exactly what you're redirected to, and which request fails.