Static libraries and frameworks are different kinds of things.
A static library is a collection of compiled object files combined into a single library file, that may be linked into an app or framework target just like single object files are linked. The difference is that only the referenced components are linked (though there is a linker option to force everything to be linked, regardless of referencing). Once linked into a target, the library's identity is lost, just like the identity of single object files is lost. In this sense, App Store submissions don't "know" whether a static library was used — there's no structural difference between an app that was built using a static library and an app that was not.
A framework is a separate target in a secondary bundle. An app with a framework is structurally different from an app without one.
The terminology is confusing here because the "library" of a static library, and the "library" of a dynamic library (which is the executable file within a built framework) aren't the same kind of library — one isn't executable, and the other is. Also, Xcode has the concept of a static library target as well as a framework target, but the products of the targets are used for different things.
In general, building your own static libraries for use in your own apps or frameworks in Xcode isn't worth the trouble. It can be helpful if you need to get pre-compiled files from a 3rd party, but keep in mind that Swift currently requires all files to have been compile with the exact same version of the Swift compiler, which often means that an older static library might not be usable in a current project without recompilation.