One example of this are tweaks that modify Cydia, which is a 32 bit app.

Entitlements

Every dylib meant for injection has to be signed to work on iOS, even if no entitlements are required. Please make sure that your toolchain of choice is producing signed dylibs, if it is a fat binary, make sure that all slices are signed.

Use ldid to sign:

ldid -S Tweak.dylib

Failure to do this will invalidate the process and make it lose all entitlements. The standard symptom is the following, but frankly, it is confusing why any binaries are in the wild that haven't at least been passed through ldid, so please don't rely on this symptom and just fix your build environment.

Granting them at runtime

To grant entitlements to a specific process in iOS 9, it seems that iOS 8's _BSAuditTokenTaskHasEntitlement function in assertiond no longer does the trick, the new _BSXPCConnectionHasEntitlement needs to be hooked instead.

Sandbox Restrictions

Tweaks that create or edit files from a sandbox application outside the app's container is no longer allowed

Use an XPC method to communicate with SpringBoard from the sandbox application

This occurs due to the change in the 32-bit pagesize on 64-bit CPUs in iOS 9. The libraries noted above need to be rebuilt with "-Wl,-segalign,4000".

Killed: 9

Pangu9 causes many command-line tools to not work, with the error "Killed: 9"

This can be solved by running "ldid -S `which <command>`"

Daemons

In iOS 9 the way daemons are loaded appears to have changed. Daemons prefixed with "com.apple" are loaded first with other daemons being loaded by launchd significantly later. This creates a bug for daemons that use XPC to communicate with SpringBoard. SpringBoard will be loaded before the daemon meaning a connection can never be established. Changing the daemon prefix to "com.apple" appears to make it load at the same time as SpringBoard allowing for the connection to succeed. More research is required into why other daemons are being loaded much later than in iOS 8.

Additionally, daemons are now outputting the error:

This daemon is not allowed to execute. Running anyway.

This can be fixed by adding the plist entry ExecuteAllowed with a boolean YES.

The Jetsam log is written to ~mobile/Library/Logs/CrashReporter however it doesnt contain anything useful. It's possible Jetsam properties are required to be added to the plist to raise the daemon's memory limit. Apples launch daemon plists use properties in a device specific globals file at /System/Library/LaunchDaemons/com.apple.jetsamproperties.N71.plist
It's not clear if you can still put the JetsamProperties keys in your daemon plist or if you need to add to the globals list, some Apple ones still have them e.g. com.apple.ac.plist.

I've tried adding overrides for custom daemons but it has no effect, still are killed when 5MB is reached.
Tweaks that erroneously add UIKit to daemons will cause them to be killed since they unexpectedly will go over 5MB.

Connecting to UNIX sockets

Tweaks built with a library injected into an app, communicating to a daemon using a UNIX a socket, might fail to connect to the UNIX socket, with error code EPERM, and the following syslog message:

Note that this worked with the original Pangu untether and has been failing to work (as described) with the latest (1.1.0) Pangu Fuxi Qin.

Update: This seems to be untrue. This doesn't work with the original Pangu untether as well. Maybe the Cydia update process has to do something with it? Maybe stashing?

A current workaround is to place the UNIX socket inside the app's sandbox.

Extension does not have filter

Starting on 0.9.6100 version of CydiaSubstrate, tweaks must specify a MobileLoader filter or Substrate will prevent the tweak from getting injected at all, with the following error:

MS:Error: extension does not have filter

canOpenURL restrictions

If you have a tweak that relies on canOpenURL it might not work because now the URLs that are allowed to be checked are required to be specified in the host app's Info.plist under LSApplicationQueriesSchemes. Unfortunately editing this list does not work because it appears to be checked at installation time, and also it can only be called with 50 URLs, once that limit is reached it fails regardless of any edits to the list. It's currently unknown where the database is stored on the device.

iOS 9 Launch scheme approval where it asks for permission to open an app:
/private/var/preferences/com.apple.launchservices.schemeapproval.plist

For error-free access to this data query the canOpenURL: status in a daemon with the appropriate entitlements or inside SpringBoard using its entitlements and make the specific query accessible over IPC using RocketBootstrap, darwin_set_state or similar if necessary.