When referring to check boxes:
Use the exact label text, including its capitalization, but don't
include the access key underscore or colon. Include the word check
Refer to a check box as a check box, not option, checkbox, or just
box, because box alone is ambiguous for localizers.
To describe user ...
The standard iOS widget for on/off settings is a switch, and not the checkbox appearance shown in your wireframes.
Note how, in the bottom-most paragraph about "using switches to manage the availability of related interface elements," it states that, if the setting is off, you can (and should ;) ) hide any further settings that relate to the toggle switch. ...
I agree with Joao's layout suggestion, because it places related options closer together (think "Gestalt Law of Proximity"), so the perception of grouping is stronger. The vertical layout also make it easier to scan the options' labels, particularly if the lengths of the labels differs quite a bit.
As for the tooltips, I ran into a similar issue in ...
Here is my suggestion:
Instead of checkboxes, use toggles since the user is "activating/deactivating" a functionality and for the help icon, show it when the user is hovering an option.
The fact that all options are vertically aligned it helps the toggles to be aligned to the left and the text readable from top to bottom.
The question mark with the black balloon icon is suitable for isolated situations, but when a full text has a tooltip icon for each option it's something totally unnecessary besides being a redundant visual noise.
The help info can appear simply when hovering the text without any extra icon.
See this example