You are required by Apple to present your own purchase UI, either something AppStore-like or an alert. After the user confirms the purchase to you, your app submits the SKPayment, which will cause the SDK to verify the user's store identity and the amount they're paying (which I believe is the second dialog that you are referring to).
Any time a user gives you money through iTunes, there will be an iTunes dialog somewhere. Apple doesn't want developers to skip that step and get free money from unsuspecting users. The solution is to design around it: you know the dialog is coming, so don't give the user a redundant dialog first. Many apps use info pages with "buy" buttons to get around that - instead of two purchase dialogs back to back, they'll see one purchase-info page, press a button, then get the Apple SDK purchase dialog.
If you want a subscription service, then you need to set the item up in iTunes Connect as a subscription, not a consumable or non-consumable item. Once you create an IAP item you cannot change its type, so choose correctly at creation time. Subscriptions aren't handled like consumables even though they are basically just time-based consumables. Apple enforces the different wording to communicate to the user that one expires at a certain date, the other expires after some non-time resource is used up.
You will need to track the subscription purchase on your own servers (to check receipts and eliminate piracy), and your apps should prompt for a renewal at the right time. As far as the app store is concerned, renewing a subscription is purchasing the subscription all over again, so, yes, you'll see the SDK throw up some dialogs at the user asking them to verify their purchase. There's currently no "auto-renewing subscription" option, either. These reasons are why many developers offer multi-month subscriptions.