Format (.a)

• This is our original architecture. You can find the latest (.a) version at http://developer.pafers.com/doc/hwapi_for_ios
  
• You should be able to submit to App Store with this (.a) library (supports arm64).
  
• PAFERS is also using this (.a) library in our Run on Earth 2 (version 1.2.4).
  
• This (.a) library supports Bluetooth Classic only (doesn't support Bluetooth Smart the future connectivity technologies).
  
• This (.a) library supports iOS 7 and/or later. We don't test and verify it on previous iOS versions.

Format (.framework) -- PFHWKIT.framework

• This is the new library architecture. We will provide (.framework) format in the future.
• PAFERS is using format (.framework) in our FitConsole (version 1.6.1).
• This (.framework) library supports Bluetooth Classic and Bluetooth Smart (a few profiles).
• This (.framework) library supports iOS 8 and/or later.
• In this new (.framework) architecture, we did some optimizations, e.g. reduced  connection speed, and improved connection stability.

Bottom Line

• You (third-party developers) have to make a decision. If you want a quick update based on current library architecture, you may want to use (.a) library format for now.
• If you are also considering about supporting future fitness machines (more machine types, more connectivity types, etc...), you should consider spending development time to implement (.framework) library format in your project(s). There's one benefit: in the future, you will implement Bluetooth Smart easier.