returning a value from asynchronous call using semaphores

I would suggest cutting the Gordian knot: You should not use semaphores to make an asynchronous method behave synchronously. Adopt asynchronous patterns, e.g. use a completion handler:

- (void)loginWithEmail:(NSString *)email password:(NSString*)password completionHandler:(void (^ __nonnull)(NSDictionary *userDictionary, NSError *error))completionHandler
{
    NSString *post   = ...; // build your `post` here, making sure to percent-escape userid and password if this is x-www-form-urlencoded request
    
    NSURL  *url      = [NSURL URLWithString:urlString];
    NSData *postData = [post dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
    
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
    [request setHTTPMethod:@"POST"];
    // [request setValue:postLength forHTTPHeaderField:@"Content-Length"];                       // not needed to set length ... this is done for you
    [request setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];  // but it is best practice to set the `Content-Type`; use whatever `Content-Type` appropriate for your request
    [request setValue:@"text/json" forHTTPHeaderField:@"Accept"];                                // and it's also best practice to also inform server of what sort of response you'll accept
    [request setHTTPBody:postData];
    
    NSURLSessionConfiguration *config = [NSURLSessionConfiguration defaultSessionConfiguration];
    config.TLSMinimumSupportedProtocol = kTLSProtocol11;
    
    NSURLSession *session = [NSURLSession sessionWithConfiguration:config delegate:nil delegateQueue:nil];
    
    NSURLSessionDataTask *task = [session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *err) {
        if (!data) {
            dispatch_async(dispatch_get_main_queue(), ^{
                completionHandler(nil, [NSError errorWithDomain:@"Connection Timeout" code:200 userInfo:nil]);
            });
        } else {
            NSError *parseError;
            NSDictionary *parsedData = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingAllowFragments error:&parseError];
            
            dispatch_async(dispatch_get_main_queue(), ^{
                if (parsedData) {
                    NSDictionary *dict = parsedData[@"User"];
                    completionHandler(dict, nil);
                } else {
                    completionHandler(nil, [NSError errorWithDomain:@"Server Issue" code:201 userInfo:nil]);
                }
            });
        }
    }];
    [task resume];
}

And then call it like so:

[self loginWithEmail:userid password:password completionHandler:^(NSDictionary *userDictionary, NSError *error) {
    if (error) {
        // do whatever you want on error here
    } else {
        // successful, use `userDictionary` here
    }
}];

// but don't do anything reliant on successful login here; put it inside the block above

Note:

1. I know you're going to object to restoring this back to asynchronous method, but it's a really bad idea to make this synchronous. First it's a horrible UX (the app will freeze and the user won't know if it's really doing something or whether it's dead) and if you're on a slow network you can have all sorts of problems (e.g. the watchdog process can kill your app if you do this at the wrong time).

   So, keep this asynchronous. Ideally, show UIActivityIndicatorView before starting asynchronous login, and turn it off in the completionHandler. The completionHandler would also initiate the next step in the process (e.g. performSegueWithIdentifier).

2. I don't bother testing for HTML content; it is easier to just attempt parse JSON and see if it succeeds or not. You'll also capture a broader array of errors this way.

3. Personally, I wouldn't return my own error objects. I'd just go ahead and return the error objects the OS gave to me. That way, if the caller had to differentiate between different error codes (e.g. no connection vs server error), you could.

   And if you use your own error codes, I'd suggest not varying the domain. The domain should cover a whole category of errors (e.g. perhaps one custom domain for all of your app's own internal errors), not vary from one error to another. It's not good practice to use the domain field for something like error messages. If you want something more descriptive in your NSError object, put the text of the error message inside the userInfo dictionary.

4. I might suggest method/variable names to conform to Cocoa naming conventions (e.g. classes start with uppercase letter, variables and method names and parameters start with lowercase letter).

5. There's no need to set Content-Length (that's done for you), but it is good practice to set Content-Type and Accept (though not necessary).